Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cuuxb.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!nwuxg!cuuxc!cuuxb!dbaker
From: dbaker@cuuxb.UUCP (Darryl Baker)
Newsgroups: net.bugs.4bsd,net.unix-wizards,net.bugs.usg
Subject: Re: Bug in isatty (all systems!)
Message-ID: <243@cuuxb.UUCP>
Date: Thu, 18-Jul-85 06:29:38 EDT
Article-I.D.: cuuxb.243
Posted: Thu Jul 18 06:29:38 1985
Date-Received: Sat, 13-Jul-85 08:24:49 EDT
References: <726@mcvax.UUCP> <965@sdcsvax.UUCP>
Reply-To: dbaker@cuuxb.UUCP (Darryl Baker)
Organization: AT&T Technologies CSD, Lisle, Il.
Lines: 25
Xref: watmath net.bugs.4bsd:1603 net.unix-wizards:13795 net.bugs.usg:249

In article <965@sdcsvax.UUCP> jww@sdcsvax.UUCP (Joel West) writes:
>> The following short C program
>> 
>> main(){
>> 	extern int errno;
>> 
>> 	errno = 0;
>> 	putchar('\n');
>> 	if(errno > 0)
>> 		perror("perror");
>> }
>> 
>> gives unexpected results.
				....
			Stuff deleted to save space
			and keep people interested.
				....
>The other 'gotcha' (same systems) is mktemp, which attempts
>to build a unique file name.  errno is always 2 (file not
>found) after successfully calling mktemp on these 3 systems.

Now I am not going to go into a long explanation of poor coding, but aren't
you supposed to check return values for errors. Lots of section 3 routines
call things from section 2 that set errno. Also isn't also true that the 
intro to section 2 states that errno is not cleared on successful calls.