scanf requirements not met?

scanf requirements not met?

[Rich Felker]

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

Re: scanf requirements not met?

[Rich Felker]

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

Re: scanf requirements not met?

[Rob Landley]

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

Re: scanf requirements not met?

[Isaac Dunham]

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>

Re: scanf requirements not met?

[Szabolcs Nagy]

* Isaac Dunham <idunham@lavabit.com> [2013-04-21 22:36:43 -0700]:
> 
> ..I'm tempted to do a diff on the two...

i made a diff after they published the draft of tc1
but they updated their html generator

this means a plain diff is big and mostly contains
html layout changes

Re: scanf requirements not met?

[LM]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

There's a tool to remove HTML so you can run a diff.  I remember it being
mentioned at this site ( http://kmandla.wordpress.com/software/ ).  See the
link to dehtml.  Am sure there are other tools that do the same thing, but
this was the first that came to mind.  I also like diffh (
http://sourceforge.net/projects/diffh/ ) for viewing the output from diff.
It can often make it easier to read.

On Mon, Apr 22, 2013 at 1:54 AM, Szabolcs Nagy <nsz@port70.net> wrote:

> i made a diff after they published the draft of tc1
> but they updated their html generator
>
> this means a plain diff is big and mostly contains
> html layout changes
>

[-- Attachment #2: Type: text/html, Size: 1014 bytes --]