Why use (void) func() ?

Henry Spencer henry at zoo.toronto.edu
Fri Sep 28 03:56:22 AEST 1990


In article <3837 at goanna.cs.rmit.oz.au> ok at 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 at zoo.toronto.edu   utzoo!henry



More information about the Comp.lang.c mailing list