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.