[ On Saturday, September 29, 2001 at 20:50:15 (-0400), der Mouse wrote: ]
> Subject: Re: ignoring return values from functions.
>
> I can't help wondering what's up with you that you feel compelled to
> present your opinions - for that's really all these are - as if they
> were facts.

These are not my opinions alone -- they are in fact as close to facts as
you can get in matters of style.  I haven't been as pedantic about
including references in this discussion as I might have been in a more
formal forum, however I have included some of them and I'm sure you can
find more on your own if you look.

> I can't think of *any* style rule that is "ALWAYS" better followed than
> ignored - with the possible (Hofstadterian :-) exception of this one: I
> think that every other style rule I've seen, I've seen exceptions to.

Sure, BUT....

This is a pretty simple rule -- and there are tools to help you be
pedantic in following it (and many widely documented reasons for being
so pedantic).  Why mess with a good thing?

> evidenced by text with homophonic mistakes, all correctly spelled (the
> "and it's advice" I quoted above is a possible example),

nah, that's just evidence of poor proofreading on my part....  :-)
(I probably didn't even mechanically spell-check that posting)

> code full of
> (void) casts serving no purpose but muffling lint's complaints
> evidences the former to me.

it's unfortunate you might think so.

Indeed when that is the case it's unfortunate because it obscures the
true intent of the programmer even more....

However to blindly assume it's true whenever you see a 'void' cast is
equally "dangerous".  It is usually not too hard to tell the difference,
at least not once you do have a deep enough understanding of any given
segment of code which exhibits this style....

> Why single out printf and fprintf?

because with printf() and fprintf() the error condition is easily
detected by other means (though unfortunately the error cause is not
preserved) and it is rarely necessary to check for an error with any
given call (though it might be beneficial in some cases where they are
used for record output without buffering, or with line-buffering).
Indeed with the normal presence of output buffering in stdio it's
unlikely there'll be any errors detectable in the return codes of all
but effectively random printf() calls.  Errors with printf()s are more
properly checked for with ferror() at pertinent times, and of course
with fclose().

[[ it would be nice if fclose() returned an error indiation if __SERR
was set when it was first called as that would eliminated having to call
ferror() first to check for any errors in previous operations...  the
only problem with this being what to put in errno.... maybe stdio should
preserve errno when it sets __SERR and then ferror() could set errno
from the preserved value.... ]]

>  Are you under the illusion that
> those are the only calls whose return values may reasonably be ignored
> all, or almost all, of the time?

Certainly they are not the only calls where error indications from
return codes can be ignored, but they are the most common of such calls
in many types of C programs.  Indeed they are often so common that
removing the unnecessary 'void' casts from even only just them alone
will usually reduce the visual clutter caused by such casts to a very
acceptable level (and thus make the remaining ones meaningful again).

In fact I've done quite a bit of experimentation with such practices
over the lifetime of several small example projects I've maintained "for
fun and profit" and as time goes by the results of these experiments
have confirmed much, if not all, of what I've said in this discussion.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>