This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/15917] New: scanf %f doesn't parse "0e+0" correctly
- From: "ats-sourceware at offog dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 31 Aug 2013 23:22:08 +0000
- Subject: [Bug stdio/15917] New: scanf %f doesn't parse "0e+0" correctly
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=15917
Bug ID: 15917
Summary: scanf %f doesn't parse "0e+0" correctly
Product: glibc
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: stdio
Assignee: unassigned at sourceware dot org
Reporter: ats-sourceware at offog dot org
With glibc 2.18, if you try to parse "0e+0" with scanf's %f format, it will
stop at the "e"; it ought to read the whole thing.
Here's an example:
#include <stdio.h>
int main() {
float a, b;
int r = sscanf("0e+0 42", "%f %f", &a, &b);
printf("r=%d a=%f b=%f\n", r, a, b);
return 0;
}
With glibc 2.18, this prints:
r=1 a=0.000000 b=0.000000
With glibc 2.13 (for example), it prints what I'd expect:
r=2 a=0.000000 b=42.000000
This is caused by an oversight in this commit, which introduced got_digit etc.
to the vfscanf %f code:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6ecec3b616aeaf121c68c1053cd17fdcf0cdb5a2
("Don't accept exp char without preceding digits in scanf float parsing")
When parsing "0e+0", the initial 0 is eaten by the code that checks for a 0x
hex prefix ("if (width != 0 && c == L_('0'))"), but that code doesn't set
got_digit to say it's seen a digit, so the "e" doesn't get treated as an
exponent marker.
Adding "got_digit = 1;" in that block fixes it for me, but you may prefer to do
something more subtle -- e.g. following the intention of the patch that
introduced the bug, it should presumably reject "0xe+0" as nonsense, so you'd
only want to set got_digit if the 0 was actually treated as a digit.
(In case it helps anyone searching for this problem: I spotted this because it
broke ATLAS's autotuning code, because masrch wrote something like "0e+00 0e+00
0e+00" to a file with printf and then failed to scanf it back in. The error
this resulted in during the ATLAS build was "xmasrch:
/src/math/atlas/work/ATLAS//tune/sysinfo/masrch.c:116: matime: Assertion
`fscanf(fp, "%lf", &mflop[i])' failed.")
--
You are receiving this mail because:
You are on the CC list for the bug.