Mail Archives: djgpp-workers/2003/08/08/13:48:03
According to Eli Zaretskii:
> > From: Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
> > Date: Fri, 8 Aug 2003 10:54:41 +0200 (MET DST)
> >
> > Because the standard says
> > " The sscanf function returns the value of the macro EOF if an
> > input failure occurs before any conversion. Otherwise, the
> > sscanf function returns the number of input items assigned,
> > which can be fewer than provided for, or even zero, in the event
> > of an early matching failure."
>
> Yes, I knew that.
>
> > If the string is "" no conversion is done, hence EOF should be
> > returned. The string "abc" should also make it return EOF, if I've
> > understood correctly.
>
> That's not my reading of the standard. ``No conversion is done''
> means we should return zero. EOF is for when there's ``an input
Read the quote above again. It says it should return EOF "if input
failure occurs before any conversion". There's is no conversion done,
agreed?
> failure'' (like if we cannot read from a file due to failure in the
> underlying DOS functions or some such). The only case in the context
> of sscanf where ``an input failure'' might happen is if the first
> argument is a NULL pointer.
comp.std.c disagree and they should know.
However my reading of the standard supports your interpretation.
I'll post to comp.std.c asking for clarification.
> So I think our implementation adhers to the standard in these cases.
>
> (IIRC, we already had a similar discussion a few years ago, but
> perhaps in the context of fscanf. It might be useful to find that
> discussion in the archives.)
I suppose that if it was fscanf() and the file contents doesn't match
we'd have an input failure too. So that one might be broken too.
Right,
MartinS
- Raw text -