[Bug stdio/13988] New: scanf %f reads too many characters on non-matching "+.e" input

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13988

             Bug #: 13988
           Summary: scanf %f reads too many characters on non-matching
                    "+.e" input
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: stdio
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bugdal@aerifal.cx
    Classification: Unclassified


I found this bug while investigating bug #12701 (my test cases attached there
will reproduce it), but it seems to be a separate issue. Bug #12701 involves
scanf wrongly accepting non-matching inputs.

Given the input "+.e", scanf (using %f) will correctly reject it as
non-matching, but will leave the file position at an incorrect offset of 3
rather than 2. In other words, it's recognizing that a degenerate floating
point value with no mantissa digits is invalid, but only after trying to parse
all the way to the end of the exponent. This is incorrect per ISO C, which
defines the input item 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".

The correct behavior would be to, upon encountering the "e" which is invalid
after a degenerate mantissa, end the scan and leave the "e" unread in the
stream.

Also, I just realized this error can be enlarged seemingly arbitrarily by
appending a pseudo-exponent. For example, given "+.e" followed by N zeros,
scanf will offset the file position by N+3 instead of by 2, an error of N+1,
and thereby thoroughly consume an integer which could otherwise be read by the
next call to scanf.

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