Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site talcott.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!tmb
From: tmb@talcott.UUCP (Thomas M. Breuel)
Newsgroups: net.lang.c
Subject: Re: casts to (void)
Message-ID: <484@talcott.UUCP>
Date: Wed, 7-Aug-85 23:30:29 EDT
Article-I.D.: talcott.484
Posted: Wed Aug  7 23:30:29 1985
Date-Received: Sun, 11-Aug-85 03:34:49 EDT
References: <11@brl-tgr.ARPA>
Organization: Harvard University
Lines: 20

In article <1310@eagle.UUCP>, mjs@eagle.UUCP (M.J.Shannon) writes:
> > In article <116@rtp47.UUCP> meissner@rtp47.UUCP (Michael Meissner) writes:
> > >Whenever I use things like printf with lint, I define things like:
> > >	#define	Printf	(void) printf
> > >	#define	Fputs	(void) fputs
> > That's a mediocre solution, it shouldn't be necessary lint should know the
> > set of standard functions which results needn't be used. It's not accept-
> > able to either put (void) in front of printf(), scanf(), ...etc. or make
> > defines like "#define Printf (void) printf".
> And programs that do this don't recover from write errors, like when a
> filesystem runs out of space.  That's what lint *correctly* complains about.

The fundamental problem here is that the way stdio indicates that
a write failed is just inconvenient. In 99.999% of all cases, you
don't want to care about failing printf's. The appropriate default 
action is to print a diagnostic message (where?) and to kill the
process, not to return a failure code that has to be checked
every single time you print something.

						Thomas.