Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.c
Subject: perror, yet again.
Message-ID: <WNW7ZR7@xds13.ferranti.com>
Date: 29 Nov 90 19:06:56 GMT
References: <1990Nov27.131327.21662@agate.berkeley.edu> <1990Nov28.152146.19560@ssd.kodak.com> <14603@smoke.brl.mil>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 41

In article <14603@smoke.brl.mil> gwyn@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@ferranti.com