From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22540 invoked by alias); 18 Apr 2012 05:42:20 -0000 Received: (qmail 22433 invoked by uid 22791); 18 Apr 2012 05:42:19 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,SARE_SUB_PCT_LETTER X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Apr 2012 05:41:25 +0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sources.redhat.com Subject: [Bug stdio/13988] New: scanf %f reads too many characters on non-matching "+.e" input Date: Wed, 18 Apr 2012 05:42:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00266.txt.bz2 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.