* scanf requirements not met?
@ 2013-04-05 1:52 Rich Felker
2013-04-20 16:51 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2013-04-05 1:52 UTC (permalink / raw)
To: musl
Hi all,
In consideration of adding the 'm' modifier for scanf and looking at
how it's supposed to handle malloc failure, I believe the current
implementation may be getting some things wrong. Seeing that it
defined malloc failure as a "conversion error":
If there is insufficient memory to allocate a buffer, the function
shall set errno to [ENOMEM] and a conversion error shall result.
I noticed that this was not either of the "failures" defined for
scanf: input or matching. The text "conversion error" does not occur
elsewhere, but the ERRORS section does specify:
If any error occurs, EOF shall be returned, and errno shall be set
to indicate the error.
The current behavior in musl is to treat EILSEQ and IO errors from the
underlying stdio layer as input failures, but in light of the above,
this seems wrong/non-conforming. It looks to me like, even if a number
of conversions have already taken place successfully, scanf is
required to return EOF anyway if an error is encountered later. This
also makes the following text make more sense:
If the function returns EOF, any memory successfully allocated for
parameters using assignment-allocation character 'm' by this call
shall be freed before the function returns.
I previously thought the only way the function could return EOF was
when no successful conversions had taken place, in which case there
would be nothing to free. But if EOF can happen even after successful
conversions, then it makes sense. (And it's also a pain to implement.)
Does this all sound right? I'll probably wait until after the release
to go working on it, and add 'm' at the same time, since scanf is ugly
and fragile and not something I want to break pending a release.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: scanf requirements not met?
2013-04-05 1:52 scanf requirements not met? Rich Felker
@ 2013-04-20 16:51 ` Rich Felker
2013-04-22 3:17 ` Rob Landley
0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2013-04-20 16:51 UTC (permalink / raw)
To: musl
On Thu, Apr 04, 2013 at 09:52:55PM -0400, Rich Felker wrote:
> Hi all,
>
> In consideration of adding the 'm' modifier for scanf and looking at
> how it's supposed to handle malloc failure, I believe the current
> implementation may be getting some things wrong. Seeing that it
> defined malloc failure as a "conversion error":
>
> If there is insufficient memory to allocate a buffer, the function
> shall set errno to [ENOMEM] and a conversion error shall result.
>
> I noticed that this was not either of the "failures" defined for
> scanf: input or matching. The text "conversion error" does not occur
> elsewhere, but the ERRORS section does specify:
>
> If any error occurs, EOF shall be returned, and errno shall be set
> to indicate the error.
Searching again, I can no longer find the text "if any error" in the
specification for scanf. It looks like TC1 has been applied to the
html version of POSIX, and the text I had cited above, which conflicts
with the requirements of ISO C, has been corrected such that an error
return only happens if the error occurs before the first conversion.
In short, we had it right and POSIX had it wrong.
There may be one remaining issue: it's not clear to me whether scanf
can return EOF after a successful match for which assignment was
suppressed with the * modifier. Such matches do not contribute to the
count returned, but by a strict reading, they seem to contribute to
the requirement to return 0 rather than EOF.
> If the function returns EOF, any memory successfully allocated for
> parameters using assignment-allocation character 'm' by this call
> shall be freed before the function returns.
With TC1 applied, this text is mostly irrelevant; it only applies to
the first conversion.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: scanf requirements not met?
2013-04-20 16:51 ` Rich Felker
@ 2013-04-22 3:17 ` Rob Landley
2013-04-22 5:36 ` Isaac Dunham
0 siblings, 1 reply; 6+ messages in thread
From: Rob Landley @ 2013-04-22 3:17 UTC (permalink / raw)
To: musl; +Cc: musl
On 04/20/2013 11:51:20 AM, Rich Felker wrote:
> On Thu, Apr 04, 2013 at 09:52:55PM -0400, Rich Felker wrote:
> > Hi all,
> >
> > In consideration of adding the 'm' modifier for scanf and looking at
> > how it's supposed to handle malloc failure, I believe the current
> > implementation may be getting some things wrong. Seeing that it
> > defined malloc failure as a "conversion error":
> >
> > If there is insufficient memory to allocate a buffer, the
> function
> > shall set errno to [ENOMEM] and a conversion error shall result.
> >
> > I noticed that this was not either of the "failures" defined for
> > scanf: input or matching. The text "conversion error" does not occur
> > elsewhere, but the ERRORS section does specify:
> >
> > If any error occurs, EOF shall be returned, and errno shall be
> set
> > to indicate the error.
>
> Searching again, I can no longer find the text "if any error" in the
> specification for scanf. It looks like TC1 has been applied to the
> html version of POSIX, and the text I had cited above, which conflicts
> with the requirements of ISO C, has been corrected such that an error
> return only happens if the error occurs before the first conversion.
Stomping the existing web copy of posix, without an obvious changelog,
really doesn't fill me with happy thoughts.
I'm glad I downloed it before they did that. I'm not quite to the point
of changing my links to point to the archive.org copy, but I do NOT
understand why a 5 year gap does not merit susv7. (Posix 2008 was not
posix 2001, so why is posix 2013 considered still posix 2008?)
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: scanf requirements not met?
2013-04-22 3:17 ` Rob Landley
@ 2013-04-22 5:36 ` Isaac Dunham
2013-04-22 5:54 ` Szabolcs Nagy
0 siblings, 1 reply; 6+ messages in thread
From: Isaac Dunham @ 2013-04-22 5:36 UTC (permalink / raw)
To: musl
On Sun, 21 Apr 2013 22:17:51 -0500
Rob Landley <rob@landley.net> wrote:
> Stomping the existing web copy of posix, without an obvious changelog,
> really doesn't fill me with happy thoughts.
>
> I'm glad I downloed it before they did that. I'm not quite to the point
> of changing my links to point to the archive.org copy, but I do NOT
> understand why a 5 year gap does not merit susv7. (Posix 2008 was not
> posix 2001, so why is posix 2013 considered still posix 2008?)
This isn't POSIX 2013, which is supposed to go to the committee shortly.
It is the "errata" from POSIX 2008.
Now, I wonder if they'd be willing to allow distribution and provide man pages like they did for POSIX 2001/2004...
Of course, it's annoying that they don't really explain what those errata are, and also that the numbers seem to have no connection to each other:
SUSv4, _XOPEN_SOURCE=700, _POSIX_C_SOURCE=200809L (IIRC).
..I'm tempted to do a diff on the two...
--
Isaac Dunham <idunham@lavabit.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-04-22 11:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-05 1:52 scanf requirements not met? Rich Felker
2013-04-20 16:51 ` Rich Felker
2013-04-22 3:17 ` Rob Landley
2013-04-22 5:36 ` Isaac Dunham
2013-04-22 5:54 ` Szabolcs Nagy
2013-04-22 11:42 ` LM
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).