This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft â Septermber 7, 2007
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 28 Sep 2012 12:27:15 +0000
- Subject: [Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft â Septermber 7, 2007
- Auto-submitted: auto-generated
- References: <bug-12437-131@http.sourceware.org/bugzilla/>
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.