Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!peregrine!ccicpg!ndjc
From: ndjc@ccicpg.UUCP (Nick Crossley)
Newsgroups: comp.lang.perl
Subject: Re: print return code bug...
Summary: Don't trust errno too much
Message-ID: <70161@ccicpg.UUCP>
Date: 7 May 90 22:31:11 GMT
References: <1990May4.202029.9341@eci386.uucp> <7996@jpl-devvax.JPL.NASA.GOV>
Reply-To: ndjc@ccicpg.UUCP (Nick Crossley)
Organization: ICL North America, Irvine CA
Lines: 30

In article <7996@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>On the other hand, perhaps I can force errno to a 0 before the fwrite()
>and then see if it gets set.  Hang on, let me try that...
>Ok, that seems to work ok.  I just hope nobody's fwrite() sets errno just
>for the fun of it.

Unfortunately, some versions of stdio do just that, such as the one I am
running on at the moment, especially on the first access to a file.  stdio
calls isatty to determine buffering strategy; isatty calls ioctl to see if
that fails.  If the ioctl fails, as it will when the file is not a terminal,
it sets errno to ENOTTY, and rather stupidly isatty leaves it set that way.

So if you do check errno after calls to stdio routines, please ignore the
stupid ENOTTY.

Similarly, people need to be careful in their error handling code.  I have
seen such stuff as :-
	if	(some system call fails)
	{
		fprintf (stderr, "nice message");
		perror or other direct usage of errno;
	}
On many systems, the perror will report 'Not a terminal' if stderr has
been redirected.  This can confuse people if the system call was something
like a disk read!
-- 

<<< standard disclaimers >>>
Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282
uunet!ccicpg!ndjc  /  ndjc@ccicpg.UUCP