Bug 860914 - C89 standard violation of %f specifier in fscanf()
C89 standard violation of %f specifier in fscanf()
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-09-27 01:31 EDT by gmper
Modified: 2016-11-24 11:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-27 14:14:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 12437 None None None Never

  None (edit)
Description gmper 2012-09-27 01:31:39 EDT
Description of problem:
There is an example in the C89 standard in the " The fscanf function" section, which describes, that %f specifier cannot read "100e", because there is no exponent part after "e"

Version-Release number of selected component (if applicable):
gcc 4.5.1

How reproducible:
#include <stdio.h>

int main(void)
    int n;
    float f;
    char c = 'x';
    n = scanf("%f%c", &f, &c);
    printf("%d %f %d\n", n, f, c);
    return 0;

Actual results:
[guest@localhost std]$ .ansi t.c -o t
[guest@localhost std]$ ./t
2 100.000000 10
[guest@localhost std]$ alias .ansi
alias .ansi='gcc -ansi -pedantic -Wall'
[guest@localhost std]$

Expected results:
from the standard '/* "100e" fails to match "%f" */'
so scanf() should return EOF

Additional info:
C99 and C11 standards contain the same example
Comment 1 gmper 2012-09-27 01:59:38 EDT
-so scanf() should return EOF
+so scanf() should return 0
Comment 2 Jeff Law 2012-09-27 14:14:59 EDT
This is a known problem with glibc's scanf implementation.  It is being tracked as bug #12437 in the glibc bug database (see External Trackers for a link).

If/when this bug is fixed upstream, we'll pick it up via our usual procedures to resync with the upstream sources.


Note You need to log in before you can comment on or make changes to this bug.