Path: utzoo!attcan!uunet!tdatirv!sarima
From: sarima@tdatirv.UUCP (Stanley Friesen)
Newsgroups: comp.unix.programmer
Subject: Re: Checking return values (was: Trojan Horses, NFS, etc.)
Message-ID: <48@tdatirv.UUCP>
Date: 26 Oct 90 14:57:51 GMT
References: <1885@necisa.ho.necisa.oz> <4315@pkmab.se> <1990Oct24.193712.8693@athena.mit.edu> <1990Oct25.075856.4923@robobar.co.uk>
Reply-To: sarima@tdatirv.UUCP (Stanley Friesen)
Organization: Teradata Corp., Irvine
Lines: 29

In article <1990Oct25.075856.4923@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
>scs@adam.mit.edu (Steve Summit) writes:
>>			default:
>>				fprintf(stderr, "%s: can't open %s: ",
>>							progname, name);
>>				perror("");
>For those of you still puzzled: perror() must be called *immediately* after the
>error returns, or the internal error state may be modified by calls
>to system calls in the intervening situation.

My solution, when I feel I *really* must place something in between the error
and the call to perror(), is to save and restore errno.  Thus:

	default:
		old_err = errno;
		fprintf(stderr, "%s: can't open %s: ", progname, name);
		errno = old_err;
		perror("");


Actually, I am likely to make the fprintf() above into an sprintf and pass
the resulting string to perror() - it gets the same results, and doesn't
involve passing an empty string to perror().

had enough?

-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)