When I came up with the name “stderr” for this blog, I was thinking about the way that the error-stream is unbuffered; that means that things come out in the order that they are printed, sort of like how I speak/write: blah blah blah unfiltered and there’s no “pause” button.

That’s all you need know about the origin of the blog name, though Crip Dyke generously [pervert justice] led an exploration into that topic.

The rest of the blog’s header is a really sick couple of old-school UNIX code jokes. The fact that nobody has found them funny so far is probably because they’re not funny.

Because I was putting them in a blog header, the lines of code are not complete. I was trying to put the tantalizing bits of lovecraftian code-horror on the left-hand side, where they belong anyhow. [It is my opinion that a line of code should do its most important thing at the left side of the line; go ahead, argue with me]

Let me walk through a few of them though:

fprintf("Oh no! System is
fprintf(stderr,"%s", strerror(errno)

What’s going on there? That’s a chunk of code I’ve seen in some commercial products, by the way. It’s why some Microsoft crap will say: “The command failed for the following reason: no error.” Here is how it works: when you use “fprintf( )” on a FILE structure, the FILE * does its own buffering, even if the output FILE * is ‘stderr’ which is supposed to be unbuffered. What happens is that fprintf( ) is usually line-buffered and flushes the buffer at a newline if the output device is a terminal. If the output is a different type of file descriptor, it may buffer the data in units of BUFSIZ, which you’d better not assume is 2k, because it has changed and when it changes, things get awkward. So, that code implements a subtle and nasty race condition because sometimes the first line may cause the buffer to flush, which invokes the system call write(2) on the underlying file description attached to the FILE *. When the write(2) completes, if it succeeds, it resets the global errno to 0, indicating there is no error condition.  When the next line comes along, it uses strerror(errno), which converts the global errno to a string, and if it’s 0, that string is “no error.”

The correct way to code that is to put the entire error processing on the same call to fprintf(), so the errno is put on the stack as it’s invoked, and you’re no longer dereferencing the global errno.

That’s an example of code that “mostly works but sometimes fails” and when I see a programmer writing that, I force a review of all the code they have put into the product.

A worse example (but too long to put in the blog header) is using memory that was allocated with malloc() after it has been freed with free(). This is a bad example:

for(x = listhead; x != NULL; x = x->next)
        free(x);

That code almost always works unless the memory item being used is small enough that the malloc() memory allocator doesn’t use some of the allocated memory to maintain a free-block list. With some malloc() implementations, like BSD’s binary buddy allocator, there is always spare memory allocated so bad coding practice like that works (or, as I prefer to say: “appears to work”) just fine. But if you put that in a small footprint system with a stingy allocator, x->next may get stepped on when the memory is put on the free block list. Best of all, when that happens the “stepped on” usually entails replacing the memory’s contents with a pointer to the next free block; which means that now the for-loop is walking the free block list, re-freeing it. Blammo. I have seen commercial products do that; suddenly they start consuming a large amount of CPU and eventually die when something hits a pointer that leads out of process memory.

The next line reads:

if(exit(1)) {

Heh, that’s ugly. exit() is the library routine (it is not a system call!) that flushes buffers for stdio and closes file descriptors and a few things, then calls the system call _exit(2) that causes the program to terminate. The code there is heinous because exit() should never return. And it certainly never should return an error, as the example indicates. Basically, that line of code says. “if you’re dead, raise your hand.” A beginning programmer might learn that “every function’s error code must be checked” and put in a check like that. If you see a programmer checking an error return from exit() – run.

To compound it, I made it worse! Our fictional programmer prints an error message:

fprintf(stderr,"Help, cannot escape!"

and then tries to kill the process using an interrupt

kill(getpid(), SIG_SEGV);

That line of code uses getpid (get the process number) then calls kill() with its own process number. Except, our fictional programmer used the wrong interrupt code – SEGV instead of KILL. SEGV is “segmentation violation” – it means the process is trying to access memory that is not active in its virtual memory tables; basically a straight-up crash. I haven’t seen anything like that in production code, but it’s a horrible possibility.

My old friend Andrew and I used to sometimes noodle about truly appalling code and would tell jokes in bad code. One of my favorites was: (let me see if I can remember how to do this… he said, as he mixed the nitric acid and the glycerine…)

jmp_buf env;

void signal_handler() {
         longjmp(env);
}

main()
{

// setup
setjmp(jmp_buf env);
signal(SIG_SEGV,signal_handler);

//run

That’s from fading memory. But here’s what it ostensibly does – it declares a global “jump” context for setjmp/longjmp, which is an old UNIX hack that allows a program to store a copy of its stack. Setjmp() stores it, longjmp() restores it – you can “jump” right out of a deeply nested call stack, but only if you are one of the worst programmers that has ever lived. Or, the best. Josh Osborne (“stripes”) implemented X-tank as a multi-threaded application using an array of jump contexts to implement internal process threading. That was disgusting and horrible but it worked fine. It was so disgusting and horrible that for a long time, that’s how POSIX threads were implemented under the hood. I looked under that hood, once, and closed it gently, and backed away. That was when I began to agree with Rob Pike, “people who want threads don’t understand fork() and exec()“. So that code sets up an error handler that restores the stack to right after the program began running at main(). Then it sets up an error handler so if there’s a segmentation fault, a wild pointer, the error handler just whacks a new copy of the stack in, and keeps running. What is terrifying is that: this works. In fact, I once did some stuff with it, where there was a global file descriptor table and the application would just “recover” by re-establishing the pointers and keep running. Why would one do this? Because memory allocators cause weird system errors when they cannot allocate more memory. A lot of programmers (myself included) allocate memory and check the return:

if((x = malloc(sizeof(thing))) == (thing *)NULL) {
          fprintf(stderr,"Cannot allocate memory: %s\n",sterror(errno));

If you have a memory allocation fail, what do you do? All you can reasonably do is a clean bomb-out. I worked briefly on a version of OSF/Mach, where the allocator sometimes returned errors for no apparent reason. What a horrible mess that was; the guys who coded that probably worked on the F-35.

When I was coding full-time, I developed my own version of malloc() which was based on the 4.2BSD version but which added a bunch of error checking. It did double-entry book-keeping on the allocator, and additionally kept a table of what line of code had allocated which blob of memory. There was a stats-keeping module that I wrote, which would dump out detailed reports of what was allocated where and how, so I could see where my programs were doing a lot of memory sucking, and sometimes I’d optimize it if it seemed necessary. It would also do things like tombstoning at both ends of a chunk of memory – so if you allocated char[20] it would allocate char[20 + (2 * sizeof(char *))] put ‘0Xdeadbeef’ at [0] and the last char *, and if those values changed, I knew something had stomped memory. My version of malloc() and free() kept a usage ticker and after 20 passes through either of those functions, it would invoke a check routine that walked all the tombstones and made sure they were intact. It also kept a table of which functions allocated the most memory, and could detect memory leaks by checking for routines that allocated but never freed memory. Developing that version took me a day or two, and it was interesting to see how the allocator worked, anyway. I used to be able to link it into other people’s code and have it spit out a litany of errors. That was good fun and saved me tons of time debugging other people’s code. I had a similar library that tracked file descriptors and routines doing file I/O. Compiling against these libraries had no effect on the code while I was developing it, and when it was time to ship the code, I’d let it link against the system libraries instead of mine.