Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP
Path: utzoo!watmath!rbutterworth
From: rbutterworth@watmath.UUCP (Ray Butterworth)
Newsgroups: net.lang.c
Subject: Re: expr?(void):(void)
Message-ID: <1688@watmath.UUCP>
Date: Fri, 1-Aug-86 14:10:26 EDT
Article-I.D.: watmath.1688
Posted: Fri Aug  1 14:10:26 1986
Date-Received: Sat, 2-Aug-86 08:04:26 EDT
References: <501@bunny.UUCP> <500@copper.UUCP> <273@watmath.UUCP> <5826@think.COM> <3502@amdahl.UUCP>
Distribution: net
Organization: U of Waterloo, Ontario
Lines: 35

> In article <5826@think.COM>, sam@think.COM (Sam Kendall) writes:
> >     void PutC(Stream, char);
> > But for efficiency you want to write PutC as a macro.  So you define it
> > like this:
> > extern void _WriteBuf(Stream);
> > #define PutC(s, c)  (--(s)->count >= 0 ? (void) (*(s)->bufp++ = (c)) \
> >                                        : _WriteBuf(s, c))
> I won't argue with the desirability of being able to do this, but
> I believe your example is poorly chosen. I/O functions can always fail
> and some indication of this ought to be returned to the user where
> possible, even though few bother to check usage like this.
> -- Jon Leech (...seismo!amdahl!jon)

But you don't know what _WriteBuf() does (neither do I).  But we
are working on a stdio-like library at waterloo which looks very
similar to this.  Checking the value returned by putchar() every
single time can be quite a waste, especially when you consider
that the only time a bad value can be returned is when the buffer
is flushed, and that only happens every 8000 characters or so
using full buffering on stdout.  It is also a pain to have to
write the code to do this check and to write whatever code is
required to handle the problem (usually print a message and exit),
especially if putchar is used in many different places in the code.
That is why "few bother to check usage like this".

The solution we use is to have the _WriteBuf function, instead of
returning an indication of error, either print the message and
exit itself, or "raise an event" that can be trapped in the user's
code (signals or longjumps).  That way users never need to check
the return status since the io function can never fail (or if it
does it doesn't return).  It makes writing correct code much simpler,
and makes previously incorrect code correct.  It also gets rid of
those thousands of useless status checks while adding no extra
overhead.  Of course this method isn't necessarily the best to use
in all cases, only in almost all cases.