scanf conflict with conclusions of WG 14 Defect Report 017 Question 29
Manuel Novoa III
mjn3@codepoet.org
Sun Nov 23 18:09:00 GMT 2003
Hello,
On Sun, Nov 23, 2003 at 12:42:02PM +0100, Petter Reinholdtsen wrote:
> [Manuel Novoa III, 2003-09-16]
> > /* glibc scanf violates the behavior specified in Defect Report #022
> > Question 29.
Sorry. That was actually supposed to be Defect Report #017, which
also references #022. The link was correct though...
http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_017.html
> I tested this, and it failed. I tried to compile it on other UNIXes
> as well, but all of them are lacking fmemopen(), so I was unable to
> test it there.
Easy enough to remove the fmemopen dependency. I used it only to
keep the test self-contained.
> On Linux, the output is
>
> fscanf returned 1, ferror=0, feof=0, and the next fgetc returned '4'
> Error: By the response to Defect Report #022 Question 29,
> scanf should have returned 0 due to a matching failure!
On Linux using glibc, yes. Essentially, glibc's fscanf is acceptiong
"1.2e+" as a valid floating point string since it returned 1 and the
next char read was '4'.
Manuel
More information about the Libc-alpha
mailing list