Date: Sat, 09 Aug 2003 11:34:51 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <7704-Sat09Aug2003113451+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <200308081747.h78HlFwQ008165@speedy.ludd.luth.se>
	(ams AT ludd DOT luth DOT se)
Subject: Re: (fwd) Re: sscanf's return value
References:  <200308081747 DOT h78HlFwQ008165 AT speedy DOT ludd DOT luth DOT se>
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

> From: <ams AT ludd DOT luth DOT se>
> Date: Fri, 8 Aug 2003 19:47:15 +0200 (CEST)
> 
> 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?

There's no conversion, but there's no ``input failure'' either (in my
opinion).

As a matter of fact, I don't understand how can _any_ input failure
happen in scanning a string, except if the string's address is
invalid, like a NULL pointer.  (Perhaps we shopuld catch SIGSEGV
inside sscanf?)  Maybe it's a good idea to ask that om comp.std.c.

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

Maybe they have a definition of an ``input failure'' that is different
from what my intuition tells me?