Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Why use (void) func() ?
Message-ID: <1990Sep27.175622.3130@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <586@dptechno.UUCP> <3819@goanna.cs.rmit.oz.au> <1990Sep25.163906.4187@zoo.toronto.edu> <3837@goanna.cs.rmit.oz.au>
Date: Thu, 27 Sep 90 17:56:22 GMT

In article <3837@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>> For printf, it is usually a whole lot simpler -- in cases where it matters,
>> which it often doesn't -- to just check ferror() near the end.
>
>I haven't a copy of the final draft of the C standard.  Does it explicitly
>say that errors detected by printf() &co set the stream's error indicator?

It says, when defining the error indicator, that it "records whether a
read/write error has occurred".  Period.  No distinction is made as to
cause of said error.

>... what about %@ or the like...

Behavior undefined.  Could cause a read/write error, I guess...

>never seen any suggestion that format errors set ferror() nor any
>guarantee that printf() doesn't clear ferror().

clearerr() and some of the fopen() family are the only things that are
documented as clearing the error indicator.  I think it is safe to say
that an indicator defined as recording "whether a read/write error has
occurred" cannot legally be implemented as "whether a read/write error
has occurred since the latest printf".

As for format errors, those clearly are not read/write errors, unless
the undefined response to them provokes one.

It should not be necessary to do a run-time check for what is invariably
a compile-time error, however, unless the printf format string is being 
synthesized in some bizarre way.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry