C is a nice little language. The syntax is, well, weird. People often complain about the parentheses in Lisp, but at least parentheses have only one meaning. In C, parentheses can mean grouping, casting, or function call -- and probably other things that don't leap to my mind immediately. Most of the other symbols in the ASCII character set have meaning as well.
Syntax aside, I think that C pretty well encapsulates everything that a basic procedural language can do. For the most part, it would be hard to improve, and remain procedural. Having said that, when I was programming in C, I couldn't help but drool over some of the features available in other languages, especially C++ and Lisp. Neither of these languages were readily available on the platforms that I was using at the time. So, I resolved to add some of the juicier features to C as a library. The CS module was the result. I can't remember why I chose the name CS, but I think it stood for either 'control structures' or 'condition system'. The principal goals of the library were to make resource management and error handling easier to do. The two main features were resource owners, roughly analogous C++ destructors or auto_ptrs, and a condition system, strongly influenced by the Common Lisp condition system. You can read the CS documentation for yourself, or browse the source: cs.h and cs.c.
Using the CS module, I found that I enjoyed programming in C much more because most of the headaches related to pointer management were handled for me. Furthermore, I could do proper error handling without having to check the error return values of every function I called. But, my enjoyment was short-lived because other, more interesting languages, soon became available to me.
Error-handling has always been a pet peeve of mine. Prior to the CS module, I used a simpler set of macros to aid in error detection and reporting. The macros were defined in trace.h and I have included a sample program to show how the macros were used. Note particularly lines like this:
C("Parse the supplied block length.")
This is an 'executable comment'. The macro would tuck the comment away somewhere so that when an unrecoverable error occurred, it was possible to get a meaningful error message -- meaningful, at least, the someone with ready access to the source code. When such an error occurred, the system would display the most recent executable comment from each stack frame. I found the resulting error messages to be extremely helpful when troubleshooting failure modes in software, whether those modes were due to a bug in the software, transient system conditions, or user error. For example:
An unforeseen error has occurred in this program.
main (153) Perform the operation.
atp_read_files (0) Scan the files on the tape.
atp_scan (0) Position the tape device.
atp_position (93) Position the tape forward the required number of tape marks.
Numeric info = 22
Possible cause: Invalid argument
Reading this traceback, one might guess that the program was trying to scan beyond the end of the last tape mark. Or not.
