Subject: Re: ignoring return values from functions.
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 09/21/2001 02:06:58
[ On Thursday, September 20, 2001 at 22:42:05 (-0700), James Graham wrote: ]
> Subject: Re: ignoring return values from functions.
>
> To address something earlier:
>
> Error checking is one thing.
>
> Pedantry is another.
Good, careful, wise, programmers are very pedantic. They check
everything, and they check it very carefuly, even if a failure "can't
happen".
You should read up on how NASA develop the space shuttle software.
Their process is quite fascinatingly bland and boring and meticulous.
It's more like auditing accounting records six ways to Sunday than
flipping bits in on the front panel for sure! Someday hopefully all
systems software and most major applications will be developed and
maintained with similar care. (I won't be holding my breath in waiting,
of course :-)
You can ignore the facts if you please, but they appear to quite clearly
show that casting function error return values to 'void' when they are
intentionally and knowingly to be ignored results in fewer errors over
the lifetime of any large body of C code; whatever the reason. The
folklore has suggested this for over a decade now, and several case
studies of large real-life systems have apparently confirmed it to be
true.
You don't have to like it -- but if you want to try to reduce errors in
your code then this is one suggestion that's had proven results and
you'd do very well to follow it. You should also learn what this idiom
means so that you can better understand third-party code you read.
Mind you you'd do even better to more carefully check and properly
handle the error return values _everywhere_. That way you won't be
littering your code with casts to 'void' because there'll be nowhere to
put them! ;-)
--
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>