This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/15917] New: scanf %f doesn't parse "0e+0" correctly


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]