This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: scanf conflict with conclusions of WG 14 Defect Report 017 Question 29
- From: mjn3 at codepoet dot org (Manuel Novoa III)
- To: Petter Reinholdtsen <pere at hungry dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Sun, 23 Nov 2003 11:09:41 -0700
- Subject: Re: scanf conflict with conclusions of WG 14 Defect Report 017 Question 29
- References: <20030916230127.GA31705@codepoet.org> <2fl3ccfwbud.fsf@saruman.uio.no>
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