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.")