Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.programmer
Subject: Re: Checking return values (was: Trojan Horses, NFS, etc.)
Message-ID: <4417@segue.segue.com>
Date: 31 Oct 90 00:18:44 GMT
References: <4315@pkmab.se> <1990Oct24.193712.8693@athena.mit.edu> <8215:Oct2521:30:3890@kramden.acf.nyu.edu> <27201@mimsy.umd.edu>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 26

In article <27201@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
[ stuff about strerror, including an implementation ]

If you use strerror to implement perror, beware of a subtle trap:

#include <errno.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
	char *	p;

	p = strerror(31415);	/* presumably unknown error */
	errno = 27182;		/* ditto */
	perror("");
	printf("%s\n", p);	
}


A naive implementation will print 27182 twice, which is wrong, because ANSI
says that the string returned by strerror may be overwritten by a subsequent
call of strerror, but it doesn't say that perror may overwrite it or that
perror may call strerror.  This and many other gotchas were known to the
committee, but unfortunately they didn't provide an implementers' guide
enumerating them.