Date: Wed, 9 Oct 1996 13:41:00 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk>
Cc: djgpp AT delorie DOT com
Subject: Re: differences in what [f|s|]scanf() returns
In-Reply-To: <7B87792A1F@fs2.mt.umist.ac.uk>
Message-Id: <Pine.SUN.3.91.961009133430.8710E-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Wed, 9 Oct 1996, A.Appleyard wrote:

>   Teun Burgers <burgers AT ecn DOT nl> wrote (Subject: Re: f2c for version 2):-
> > ... You need to change about fscanf() in format.c, i.e.
> > from:     if (fscanf (infile, "%d", &token) == EOF)
> > to:     if (fscanf (infile, "%d", &token) == NULL)
> > Because return value of fscanf() of V2 is different from UNIX ...
> 
> Oh indeed!?!?!? Qu'vatlh!!! And I recently wrote and allowed out a C++ program
> that relies on sscanf() returning n if it managed to read the 1st to nth of
> the values that it was supposed to read! Which C's and C++'s do treat fscanf()
> sscanf() scanf() this way? And which otherwise, and what do they do here?

That's a bug in v2.0 library.  v2.01 corrects it, so there's no need to 
worry too much.

Btw, the bug only emerges when not a single value was read (instead EOF, 
a 0 is returned), so if you only test for values [1..n] you're OK.

As another btw, the change suggested above is incorrect, strictly 
speaking, because `fscanf' returns an int, not a pointer.  So you should 
say thus:

	if (fscanf (infile, "%d", &token) == 0)

In fact, the most robust way to write this in a way that will always work 
(in other environments as well) is like so:

	if (fscanf (infile, "%d", &token) <= 0)