This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: scanf conflict with conclusions of WG 14 Defect Report 017 Question 29


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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]