[net.lang.c] Error Checking in C

mayer (10/26/82)

I would like to hear about styles of error checking in C.  The standard
technique is to return status values from functions, and to check the
results after each call.  Unfortunately, this obscures the normal flow
of control.  When I want to say:

	source = fopen(source_file, "r");

I have to write:

	source = fopen(source_file, "r");
	if (source == NULL) {
		...
		}
or
	if ((source = fopen(source_file, "r")) == NULL) {
		...
		}

How many people do you know that check for errors after a write?

Most modern languages, such as MESA or ADA, have explicit exception
handling constructs.  Would exception handling be a good extension to
C?  Would style conventions help?  Are things ok as they stand?

			Trembling, but nevertheless willing to sign my name
			Jim Mayer
			seismo!rochester!mayer
			allegra!rochester!mayer

woods@sri-unix (10/28/82)

  The one error check that I would like to see (perhaps as an option on
the "cc" command line, as it is with our FORTRAN compiler) would be array
bounds checking. You could still get around the checking if you really
did want to refer to something outside the boundary by using the pointer
form. Another thing that would be halpful is a traceback dump, i.e.
"aborted in routine blotto, line n". Somehow I find
"segmentation viloation, core dumped" totally unacceptable as a diagnostic.
It might as well just say "hey, stupid, you fucked up!" because it really
doesn't convey much useful info. Is there a good reason (i.e. inefficiency,
difficulty of implementation) that these things aren't available? Are/will
they be available in other C compilers?

               GREG (menlo70!hao!woods or hplabs!hao!woods)

P.S. Sorry to bore all the C wizards, I am fairly new to C programming.
Better send replies to me personally and not the net, unless you really
feel it is of general interest to C programmers.

minow (11/01/82)

Greg (hao!woods) asked for some form of traceback.  I implemented this
as an option to Decus C.  It should be fairly simple to add to Unix
C's as well.  If the program was compiled with profiling, the function
name is available (as an ascii string) in the memory image.  If the program
aborts, the library routine that is run by the operating system
unwinds the call frame, using magical methods to locate the string.
It then prints out something like:
	[main process subroutine function 01234 foobar error]
where "01234" is the location of a routine that wasn't compiled with
profiling.  There are a huge number of sanity checks to unwind safely.

The routine also dumps registers and a few other things.

Having the function name string in memory offers some other advantages.
For example, I wrote the "caller()" function that returns a pointer to
the name of the routine that called the function calling caller().
Also,

	extern FILE	*$$flow;

	$$flow = stderr;
	foo();
	bar();
	$$flow = NULL;

Setting $$flow to a non-null FILE * causes the register save routine to
print the name of the function being invoked and one or two other values.

It is quite easy to add statement (or line) number tracing to C.
The compiler must generate one of two instructions at each line or
statement:

	mov	#number,@__nbrptr		Set current line number
or	inc	@__nbrptr.

At the entry to a function, a local trace block is built (and linked
into the caller's).  __nbrptr contains the address of the current trace block.
This technique has been available on Dec's PDP-11 Fortran compilers for
many years.

Martin Minow
decvax!minow

swatt (11/02/82)

UNIX gives you a cryptic message and a core dump instead of a
traceback message because given the core image and a reasonable
debugger, you can quickly find out everything a traceback message
would give you plus a lot more.  That being the case, it's obtrusive
to tell you any more than your program blew up, and you have a
core image to work with to find out why.

It is unfortunate the UCB people broke adb's ability to deal
with local symbols when they went to arbitrary length identifiers,
but even so, it makes a pretty good post-mortem tool.

I can't imagine I'd find traceback messages useful in a UNIX
environment that already gives me a decent debugger.

	- Alan S. Watt

tim (11/02/82)

Although it is fairly easy to use adb or sdb on a
core image, a traceback would do the same thing
both (a) more easily and (b) for novice users who
don't know adb from a giant ant. I struggled along
for weeks after moving to UNIX before discovering
the debuggers' proper use. In any case, the messages
"segmentation fault" and "bus error" are atrocities:
for most of us, they were a total mystery for a while.
Even now, I only know what they are, I don't know why
they're called that.

People seem to be willing to suggest introducing error
handlers into C without giving any idea of the desired
syntax or explaining why they don't like signal(2).
I would like to see the default error handlers extended,
but I have no problems with using signal. Perhaps a
slightly modified signal should be made part of the
language.

					Tim Maroney
					unc!tim