From: <ams AT ludd DOT luth DOT se>
Message-Id: <200308081747.h78HlFwQ008165@speedy.ludd.luth.se>
Subject: Re: (fwd) Re: sscanf's return value
In-Reply-To: <2427-Fri08Aug2003175605+0300-eliz@elta.co.il> "from Eli Zaretskii
 at Aug 8, 2003 05:56:06 pm"
To: djgpp-workers AT delorie DOT com
Date: Fri, 8 Aug 2003 19:47:15 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-MailScanner: Found to be clean
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Eli Zaretskii:
> > From: Martin Stromberg <eplmst AT epl DOT ericsson DOT se>
> > Date: Fri, 8 Aug 2003 10:54:41 +0200 (MET DST)
> > 
> > Because the standard says 
> > "    The sscanf function returns the value of the macro EOF if an 
> >      input failure occurs before any conversion.  Otherwise, the
> >      sscanf function returns the number of input items assigned,
> >      which can be fewer than provided for, or even zero, in the event
> >      of an early matching failure."
> 
> Yes, I knew that.
> 
> > If the string is "" no conversion is done, hence EOF should be
> > returned. The string "abc" should also make it return EOF, if I've
> > understood correctly.
> 
> That's not my reading of the standard.  ``No conversion is done''
> means we should return zero.  EOF is for when there's ``an input

Read the quote above again. It says it should return EOF "if input
failure occurs before any conversion". There's is no conversion done,
agreed?

> failure'' (like if we cannot read from a file due to failure in the
> underlying DOS functions or some such).  The only case in the context
> of sscanf where ``an input failure'' might happen is if the first
> argument is a NULL pointer.

comp.std.c disagree and they should know.

However my reading of the standard supports your interpretation.

I'll post to comp.std.c asking for clarification.

> So I think our implementation adhers to the standard in these cases.
> 
> (IIRC, we already had a similar discussion a few years ago, but
> perhaps in the context of fscanf.  It might be useful to find that
> discussion in the archives.)

I suppose that if it was fscanf() and the file contents doesn't match
we'd have an input failure too. So that one might be broken too.


Right,

						MartinS