[Bug libc/12437] New: scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[Bug libc/12437] New: scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[hjl.tools at gmail dot com]

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

           Summary: scanf behavior differs from WG14/N1256 Committee Draft
                    — Septermber 7, 2007
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: hjl.tools@gmail.com


Page 300 in

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

says "100e" shouldn't match "%f". But I got

[hjl@gnu-6 tmp]$ cat s.c
#include <stdio.h>

int main()
{
  int count;
  float quant;
  char buf[100];
  count = fscanf(stdin, "%f%s", &quant, buf);
  printf ("quant = %lf\n",quant );
  printf ("count = %d\n", count);
  printf ("string = %s\n", buf);
  return 0;
}
[hjl@gnu-6 tmp]$ gcc s.c
[hjl@gnu-6 tmp]$ cat x.input 
100ergs of energy
[hjl@gnu-6 tmp]$ ./a.out  < x.input 
quant = 100.000000
count = 2
string = rgs
[hjl@gnu-6 tmp]$ 

I was told that Windows and MacOS behave the same as glibc.

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

[Bug libc/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[drepper.fsp at gmail dot com]

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

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-01-25 20:45:56 UTC ---
The implementation is correct.  The implementation must behave as if at most
one character can be pushed back.  Since only after the 'r' is read the mistake
is found the result is rgs for the string.

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

[Bug libc/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|INVALID                     |

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2011-10-07 04:24:05 UTC ---
This bug is valid. Nobody is claiming scanf should pushback two characters, but
it needs to report a matching failure rather than accepting "100e" as if it
were a valid floating point representation. The C standard could not be more
explicit on this matter.

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

[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |stdio

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

[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[bugzilla-mail-box at yandex dot ru]

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

gmper <bugzilla-mail-box at yandex dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla-mail-box at yandex
                   |                            |dot ru

--- Comment #3 from gmper <bugzilla-mail-box at yandex dot ru> 2012-09-28 04:53:12 UTC ---
Why shouldn't the scanf() function read "100" from "100e" ?
If it shouldn't read even "100" from "100e" (according to the standard), what
it should leave in the input stream after that matching failure ? What is the
next character during the next call of a reading function ?

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

[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[bugdal at aerifal dot cx]

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

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> 2012-09-28 12:27:15 UTC ---
> Why shouldn't the scanf() function read "100" from "100e" ?

Formally, because it's specified not to. See 7.19.6.2:

"An input item is read from the stream, unless the specification includes an n
specifier. An input item is defined 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.251) The first character, if any, after the input
item remains unread.

... If the input item is not a matching sequence, the execution of the
directive fails: this condition is a matching failure. ...

...

251) fscanf pushes back at most one input character onto the input stream.
Therefore, some sequences that are acceptable to strtod, strtol, etc., are
unacceptable to fscanf."

Conceptually, because scanf only has one character of "lookahead". "100e" is
all read because it's a valid initial sequence of a floating point string. The
next character (or EOF) is then inspected and seen not to match, and thus left
unread. And the directive is required to fail. glibc basically does this except
it wrongly makes the directive succeed and assigns a value to the invalid
partial float string.

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

[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12437

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |fweimer at redhat dot com
         Resolution|---                         |DUPLICATE

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
Duplicate of bug 12701.

*** This bug has been marked as a duplicate of bug 12701 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/12437] scanf behavior differs from WG14/N1256 Committee Draft — Septermber 7, 2007

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12437

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.