perror/strerror after fopen (was FILE *fp[];)

[Chris Torek]

>In article <1990Nov28.152146.19560 at ssd.kodak.com> weimer at ssd.kodak.com
suggests error reporting of the form:
>>    if ((fp[i]=fopen(file_name[i],"r+")) <= 0)
>>        perror("Error opening file");

In article <14603 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
>Please don't do this; on UNIX, perror() will report the reason for the last
>SYSTEM CALL failure, not the reason for failure of a library routine such as
>fopen().  Sometimes there is a close relation between these but at other
>times there is not, leading to such absurd diagnostics as "Error opening
>file: not a tty".

Some of us regard this as a bug, rather than a feature.  I am not
particularly happy with the whole idea of a global `error number',
but there it is.  To make the best of it, the 4.4BSD C library
guarantees that errno *is* meaningful after an error.

It is, of course, true that errno has no portable meaning after an
fopen failure.  Still, you could print something like:

	(void) fprintf(stderr,
	    "%s: error opening file %s for read-update\n"
	    "\tlast system error was %s\n",
	    progname, file_name[i], strerror(errno));

This gets all the facts across, and is helpful when trying to figure
out *why* the open failed.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris