Error Return (was Re: (char *)(-1))
Steve Hosgood
iiitsh at cybaswan.UUCP
Thu Aug 3 20:27:03 AEST 1989
I am of the opinion that the historical reason for returning -1 for errors
came from the fact that a lot of code can then be written:
if ((foo = bar()) < 0) {
<error code here>
}
..which will compile neatly on most machines since all you do is test the
'N' flag (or whatever) which is usually present in architectures, and can
be tested quickly.
I notice that assembler programmers often return error status by setting the
carry-bit however, this lets them still return an error value *and* flag the
fact that an error has occurred all in one go.
There is no prior art, but I've often wished for a way to do this in 'C'.
Consider the advantages:
The error return is unambiguous.
The actual value that *does* get returned can be treated specially once it
is known that an error occurred.
The 'errno' system could probably be scrapped (I never liked it much anyway).
Trouble is - how to you express a test of the carry-bit? Really it will need
a syntactical addition to the language to be neat, and that is unlikely to
be acceptable.
I guess that an extension of the form:
if (errval(foo = bar())) {
<error code goes here>
<could use 'foo' to get more details of the error>
}
..would be most acceptable. 'errval' could be made a reserved word on new
systems (tests the carry bit), and implemented as a macro on older ones for
backward compatability:
# define errval(x) (x) < 0
..or
# define errval(x) (x) == -1
..or something like that, though some sort of cast will be reqd of course.
Just an idea.
Please contribute *arguments* for or against, not flames.
Steve
-----------------------------------------------+------------------------------
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: iiit-sh at uk.ac.swan.pyr
Swansea SA2 8PP | UUCP: ..!ukc!cybaswan.UUCP!iiit-sh
----------------------------------------+-------------------------------------
My views are not necessarily those of my employers!
More information about the Comp.std.c
mailing list