[Bug stdio/12437] scanf behavior differs from WG14/=?UTF-8?Q?N1256=20Committee=20Draft=20=E2=80=94=20Septermber=207?=, 2007

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=12437

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> 2012-09-28 12:27:15 UTC ---
> Why shouldn't the scanf() function read "100" from "100e" ?

Formally, because it's specified not to. See 7.19.6.2:

"An input item is read from the stream, unless the specification includes an n
specifier. An input item is defined as the longest sequence of input characters
which does not exceed any specified field width and which is, or is a prefix
of, a matching input sequence.251) The first character, if any, after the input
item remains unread.

... If the input item is not a matching sequence, the execution of the
directive fails: this condition is a matching failure. ...

...

251) fscanf pushes back at most one input character onto the input stream.
Therefore, some sequences that are acceptable to strtod, strtol, etc., are
unacceptable to fscanf."

Conceptually, because scanf only has one character of "lookahead". "100e" is
all read because it's a valid initial sequence of a floating point string. The
next character (or EOF) is then inspected and seen not to match, and thus left
unread. And the directive is required to fail. glibc basically does this except
it wrongly makes the directive succeed and assigns a value to the invalid
partial float string.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.