🚀 go-pugleaf

In article <16406@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <1990Apr6.102819.9379@bath.ac.uk> exspes@bath.ac.uk (P E Smee) writes:
>>In fact, I tend to the opinion that any N-possibility operation (function,
>>whatever) should offer an N+1st value which means 'I couldn't tell'.  ...
>>Consider the ERROR value to be an 'out-of-bandwidth' value which is
>>coincidentally returned down the same channel -- much as EOF in get*.
>
>That can work when N is small, but you start to have problems with a function
>whose valid return values span the entire universe of its natural type.  The
>`getchar()' function was kludged in by declaring it `int' instead of the more
>natural `char', but there's no such simple remedy for `atoi()'.

Too true.  I think my *real* opinion is that I don't really mind
whether you add out-of-band error values or not, as long as you're
consistent.  (Just in case I ever have to take over the code. :-)
I assume that anyone who uses TRUE/FALSE/ERROR 'two-states' will write
their code to work with them.

It also demonstrates a weakness which is the price you pay for C's
(usually handy) orientation of 'everything's a function, and you don't
have to worry about protecting arguments because it's pass-by-value'.
That approach has a lot of good points, but the down side is that there
is no 'easy and aesthetically pleasing' way of getting both a return
value, and a success/failure indication, out of a function.  (Have to
design one when I invent MY language. :-)

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132