public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug stdio/15917] New: scanf %f doesn't parse "0e+0" correctly
@ 2013-08-31 23:22 ats-sourceware at offog dot org
  2013-08-31 23:26 ` [Bug stdio/15917] " ats-sourceware at offog dot org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: ats-sourceware at offog dot org @ 2013-08-31 23:22 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-06-13 12:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-31 23:22 [Bug stdio/15917] New: scanf %f doesn't parse "0e+0" correctly ats-sourceware at offog dot org
2013-08-31 23:26 ` [Bug stdio/15917] " ats-sourceware at offog dot org
2013-09-01  3:42 ` bugdal at aerifal dot cx
2013-10-29 13:32 ` schwab@linux-m68k.org
2013-10-30  1:48 ` bugdal at aerifal dot cx
2013-10-30 13:58 ` erik at ixsop dot nl
2013-10-31 11:59 ` schwab@linux-m68k.org
2013-10-31 12:00 ` ats at offog dot org
2014-06-13 12:58 ` fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).