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