perror, yet again.

[Peter da Silva]

In article <14603 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes about
code like:
> >    if ((fp[i]=fopen(file_name[i],"r+")) <= 0)
> >        perror("Error opening file");

To begin with <0 is a valid return value for fopen(), but aside from that:

> 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".

In every case where I've got the source to a program and have figured out
where something like that came from it's been one of the two following
cases:

	if(!(fp = fopen(...))) {
		fprintf(stderr, "%s: ", argv[0]);
		perror(...);
	}

(where the fprintf stomped on errno when deciding what buffering to do) or:

	if(!(fp = fopen(...))) goto cleanup;
	if(!something...else) goto cleanup;
	...
cleanup:
	perror();

(where the error might not have had anything to do with stdio). In general
the simple code:

	if(!(fp = fopen(...))) {
		perror(...);
		...
	}

does a perfectly adequate job of printing a usable error message. It would
be nicer to have ferror(fp) return an error number suitable for feeding
to strerror(), but in the meantime it's better than nothing.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter at ferranti.com