Path: utzoo!attcan!uunet!mcvax!ukc!reading!cf-cm!cybaswan!iiitsh From: iiitsh@cybaswan.UUCP (Steve Hosgood) Newsgroups: comp.std.c Subject: More thoughts on "Error Return" Keywords: error, flag, exception Message-ID: <601@cybaswan.UUCP> Date: 9 Aug 89 12:06:32 GMT References:<594@cybaswan.UUCP> Reply-To: iiitsh@cybaswan.UUCP (Steve Hosgood) Organization: Institute for Industrial Information Technology Lines: 176 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@june.cs.washington.edu (David Keppel) > Date: 4 Aug 89 17:09:21 GMT > Organization: University of Washington, Computer Science, Seattle > Lines: 16 > > iiitsh@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@piring.cwi.nl (Siebren van der Zee) > From: david@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@utzoo.uucp (Henry Spencer) > Date: 5 Aug 89 22:33:31 GMT > Organization: U of Toronto Zoology > > In article <8314@boring.cwi.nl> siebren@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@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@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@ficc.uu.net (Peter da Silva) > Date: 7 Aug 89 13:36:29 GMT > Organization: Xenix Support, FICC > > In article <26998@agate.BERKELEY.EDU>, mwm@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@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@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