Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!bionet!ames!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: perror/strerror after fopen (was FILE *fp[];)
Message-ID: <28078@mimsy.umd.edu>
Date: 29 Nov 90 08:15:55 GMT
References: <1990Nov27.131327.21662@agate.berkeley.edu> <14603@smoke.brl.mil>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

>In article <1990Nov28.152146.19560@ssd.kodak.com> weimer@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@smoke.brl.mil> gwyn@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@cs.umd.edu	Path:	uunet!mimsy!chris