Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!reading!onion!riddle!domo
From: domo@riddle.UUCP (Dominic Dunlop)
Newsgroups: comp.sources.bugs
Subject: Re: Compress error message (really Reason for Not a typewriter)
Message-ID: <479@riddle.UUCP>
Date: Tue, 8-Sep-87 14:07:25 EDT
Article-I.D.: riddle.479
Posted: Tue Sep  8 14:07:25 1987
Date-Received: Sat, 12-Sep-87 04:44:04 EDT
References: <339@cbstr1.att.com> <209@ho7cad.ATT.COM>
Reply-To: domo@riddle.UUCP (Dominic Dunlop)
Organization: Sphinx Ltd., Maidenhead, England
Lines: 27
Keywords: errno, stdio, perror, ENOTTY
Summary: Results from stdio package affecting errno

Nobody seems to have posted anything quite like this (although some are
quite close), so stand back while I demonstrate my prowess (you might just
get bored to death)...

An unexpected ``Not a typewriter'' message is usually the result of
perror() being called after some standard I/O operation which the caller
deems to have failed, but which has not actually made a failing system
call.  The reason is that, any time standard I/O opens an output file,
it tries a terminal-specific ioctl().  If the call succeeds, stdio knows
that it should send the output to the file without (much) buffering.  If it
fails, buffering is desirable for efficiency.  A failed ioctl() leaves
ENOTTY in errno, the location used by perror() to index into the table of
error messages.  As the errno value hangs around until the programmer
explicitly clears it (and most programmers don't bother), it's liable to
get picked up if perror() is called much later following an operation which
the programmer considers to be a failure, but which the kernel doesn't.
If the programmer clears errno before such an operation, and calls perror()
afterwards, another helpful message such as ``(null)'' may well result.

The moral of this story is that the only time it's safe to use perror()
to report problems is when a failure's so obvious that even the kernel's
noticed.  Why compress fails in this way on encountering the ulimit (boo,
hiss), rather than primly reporting an EFBIG error is beyond me.  Can I be
bothered to look at the source?  No (the pubs are open).

Dominic Dunlop
domo@riddle.uucp  domo@sphinx.co.uk