Path: utzoo!attcan!uunet!lll-winken!ames!xanth!mcnc!ecsvax!dukeac!bet
From: bet@dukeac.UUCP (Bennett Todd)
Newsgroups: comp.lang.c
Subject: Re: lint question
Message-ID: <1188@dukeac.UUCP>
Date: 16 Jan 89 19:22:36 GMT
References: <491@babbage.acc.virginia.edu>
Reply-To: bet@dukeac.UUCP (Bennett Todd)
Organization: Academic Computing, Duke University, Durham, NC
Lines: 37

>Lint complains: 
>
>function returns value which is always ignored
>    fprintf	    printf
>
>Is it bad style to use these functions without also checking the 
>returned value?

*All* possible error routines should be checked, with only one exception that
I know of:

	if (fatal failure) {
		(void) fprintf(stderr, "suitable error message");
		exit(error_level);
	}

There's no point in checking for an error writing to stderr, since you
couldn't report it anyway, and all you are going to do is exit.

I found that wrapping suitable error checking and disposal around every last
function call got tedious, fast. So, I started a library of routines (up to 20
now; I add more as needed) which are simply wrappers around system calls
(section 2 UPM) and library routines (section 3 UPM) which check the status of
the called routine, and if it failed, print a suitable message and exit. So,
in the usual case (seems to be better than 90% of the time) I just use the
efunc_name() routine and am done with it. For example, ewrite() and efwrite()
are of type void, whereas efopen() is of type FILE * and guaranteed to return
a valid FILE pointer (or not come back at all). As long as I was inserting my
own layer between my code and stdio, I added as a frill cacheing filenames in
eopen() and efopen(), for use in diagnostic messages. Also, emalloc() prepends
and appends validation signatures to each allocated unit, which erealloc() and
efree() check. So, diagnostics are delivered as soon as possible after you
corrupt the malloc arena. This sort of approach makes life much easier for me
in writing and debugging programs.

-Bennett
bet@orion.mc.duke.edu