More thoughts on "Error Return"

[Steve Hosgood]

Netreaders will remember my original article a week or so ago that discussed
adding the ability for C functions to return unambiguous error
indications without all the problems currently encountered. I've been well
pleased with the replies I've read. Below are my answers to some of the
comments I've seen.

> From: pardo at june.cs.washington.edu (David Keppel)
> Date: 4 Aug 89 17:09:21 GMT
> Organization: University of Washington, Computer Science, Seattle
> Lines: 16
> 
> iiitsh at cybaswan.UUCP (Steve Hosgood) writes:
> >[errval(foo())]
> 
> Until it is `prior art', it probably doesn't belong in dpANS C.
> 
> Often, `-1' is used as a return value for things that can be array
> indicies, because `-1' can't be an array index.  Having `errval'
> requires that you know not just the return type, but also which kinds
> of values are going to be meaningful (since, e.g., not all compilers
> have condition codes).  To do this `right', you need a stronger typing
> system than C provides.
> 

My 'errval' macro that checks for 'x < 0' or possibly 'x == 1' was intended as
a way for users with older compilers without the proposed feature to 'fake' it
fairly easily. Obviously, you have no type-checking with a macro, and you're
reliant on the actual return value to tell you there's an error, so the macro
you use will often have to be tailored to the function that you called.
'Errval' (or whatever) *must* be implemented by the compiler so as to work
properly.

> From: siebren at piring.cwi.nl (Siebren van der Zee)
> From: david at psitech.UUCP (david Fridley)
> Date: 5 Aug 89 20:41:45 GMT
> Organization: PsiTech Inc., Fountain Valley, CA
> 
> Wouldn't it be nice if you could return more than one value from a C function?
> ie:
> 	(ret1,ret2)=func(param1,param2,param3);
> I believe this would solve error problems, and many others that I have had.
>

I've often though about this, but can't think up a sensible methodology. The
idea of passing a boolean WIN/LOSE flag along with the normal return value is
managable (I think), let's see if anyone out there can come up with a multiple
return value scenario. Oh, and don't use a comma to seperate the multiple
targets of the assignment - comma is already used for other things, and we
can't have a context sensitive grammar! See later.

> Date: 4 Aug 89 19:40:24 GMT
> Organization: CWI, Amsterdam
> 
> Ok, and now the hard part: what should the code from the
> CALLED function look like?
> 

Oops, I left that out of the posting! Sorry. Actually, Henry Spencer's
posting and my reply just about answer this question - read on.

> From: henry at utzoo.uucp (Henry Spencer)
> Date: 5 Aug 89 22:33:31 GMT
> Organization: U of Toronto Zoology
> 
> In article <8314 at boring.cwi.nl> siebren at piring.cwi.nl (Siebren van der Zee) writes:
> >>[errval(foo())]
> >Ok, and now the hard part: what should the code from the
> >CALLED function look like?
> 
> The obvious thing to do is to have two different kinds of "return" statement,
> one for normal and one for errors.  That completely hides how the "error"
> flag is passed back.  Unfortunately, it is awkward on some machines, where
> there are no condition codes.
> 

As I said above, I forgot to mention this bit in my posting. Two different
return statements would do the trick, but I'd rather see a way of passing
the 'error' flag from a variable. I'd like to see any extension involve the
least number of new reserved-words - this proposal requires 'ereturn' or
something similar to be reserved. Also, I consider it neater to have my
routines terminate in a single 'return' statement, and having to use two
differnt types of 'return' in order to pass the 'error' flag rather precludes
this.

So: maybe something like

	...
	return val, err;

..would do the trick. I don't seriously want to use a comma seperator though,
as it's already used for other things. Trouble is, I can't think of any
other unused seperator. The guy (see above) who proposed the more general
multiple value return mechanism used commas too. Better find another symbol.
Double colon might work - but I think that's used by C++ and that could cause
problems if 'C' started to employ it too.

Let's see:

	...
	return val::errflag;

..seen worse, though C++ boys will be hammering on the door any minute now!.
 
> Interested parties, note:  the idea is *guaranteed* to go nowhere unless
> you are interested enough to implement it in a compiler.
> -- 

..yeah, but if you implement such a concept in a compiler, you've just put
an extension into it, and that would start to undo all the standards effort
straight away. I hate 'extended' languages - DEC and HP are my least favorite
language vendors for this very reason. It's all a bit 'chicken and egg' if
ANSI won't consider it until someone implements it.

> From: mwm at eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
> Date: 5 Aug 89 04:46:49 GMT
> Organization: Missionaria Phonibalonica
> 
> How about:
> 
> #define errval(x)	(errno = 0, (x), errno)
> 
> It'll even work on the current standard. Whether you can get this to
> turn into tweaks to the carry flag (I hope that nobody would advocate
> referring to hardware flags in the standard; there's already hardware
> that C runs on without such flags) in a standard-conforming compiler
> is an interesting question.
> 

I agree, the standards mustn't refer to the 'carry' flag. Chances are that
many implementors would use the carry flag though - if there is one on the
hardware.

> From: gregg at cbnewsc.ATT.COM (gregg.g.wonderly)
> Date: 6 Aug 89 22:38:46 GMT
> Organization: AT&T Bell Laboratories
> 
> I have always liked the idea of having the types of information that VMS
> provides in condition codes.

All I'm trying to suggest is a method for giving the caller of a C-routine
the information that a failure occurred. Once he knows that it failed he can
go find out the real reason. Often that will be to check the actual return
value, or possible the 'errno' external variable.

What Gregg's doing (I think) is proposing a more powerful 'errno' variable.
I *think* this a parallel thread. Redefining 'errno' requires no changes to
'C' - just a change in accepted procedure by the writer and users of standard
library routines. To be honest - I dislike the VMS approach... too heavy, man! 

> From: peter at ficc.uu.net (Peter da Silva)
> Date: 7 Aug 89 13:36:29 GMT
> Organization: Xenix Support, FICC
> 
> In article <26998 at agate.BERKELEY.EDU>, mwm at eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
> > #define errval(x)	(errno = 0, (x), errno)
> 
> This is how you get programs that spit out messages like:
> 
> 	"peter at ficc.uu.net: Not a tty"
> 

IMHO, the error message quoted is due to sloppy programming rather than
an error-return mechanism. Some routine returned an error, it's just been
mis-interpreted.

Mind you, it's not *that* wrong either. You're *not* a tty are you Peter? :-)

-----------------------------------------------+------------------------------
Steve Hosgood BSc,                             | Phone (+44) 792 295213
Image Processing and Systems Engineer,         | Fax   (+44) 792 295532
Institute for Industrial Information Techology,| Telex 48149
Innovation Centre, University of Wales,        | JANET: iiitsh at uk.ac.swan.pyr
Swansea SA2 8PP                                | UUCP: ..!ukc!cybaswan!iiitsh
-----------------------------------------------+------------------------------
            My views are not necessarily those of my employers!
           Please note the change in my username as of 1 Aug '89