Mail Archives: djgpp/2004/09/02/20:30:22
On Thu, 2 Sep 2004 18:30:56 -0400 in comp.os.msdos.djgpp, DJ Delorie
<dj AT delorie DOT com> wrote:
>
>> -- I'm becoming more and more confident, that it's actually
>> inconsistent with the current implementation.
>>
>> To return EOF, the input has to end *before* the first item
>> converted/assigned, because when it has to end otherwise? It has to
>> end sometime... No word about conversion items pending.
>
>The documentation is vague (heck, the standard is a little vague too).
>The problem is that it doesn't say what happens when they're
>successful conversions AND input ends prematurely. The normal case is
>that you have a conversion for all your format specifiers before input
>ends. The other two cases are a conversion error (wrong input) or end
>of string (no input).
ISTM the standard clearly specifies only input failure *before* any
conversion occurs results in EOF: any matching failure results in the
number of matched, converted and assigned items being returned, which
may be zero:
"7.19.6.2#16 The fscanf function returns the value of the macro EOF if
an input failure occurs before any conversion. Otherwise, the 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."
>The appropriate test cases are thus, for "%d %d":
IMHO according to info and standard, results should be:
> ""
input failure - terminator - returns EOF
> "x"
matching failure - returns 0
> "5"
input failure - terminator - returns 1
> "5 x"
matching failure - returns 1
> "5 5"
success - returns 2
> "5 5 x"
success - returns 2 - " " scanned and pushed back - "x" unscanned
>
>The first and third are the problem cases here.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian DOT Inglis AT CSi DOT com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
- Raw text -