“It Can’t Be a Bug, My Makefile Depends on It!” 187 it crashes is to run every program from your debugger.2 If you want to debug interrupts, your debugger program must intercept every interrupt and forward the appropriate ones to your program. Can you imagine running an emacs with three context switches for every keystroke? Apparently, the idea of routine debugging is alien to the Unix philosophy. Date: Wed, 2 Jan 91 07:42:04 PST From: Michael Tiemann cygint!tiemann@labrea.stanford.edu To: UNIX-HATERS Subject: Debuggers Ever wonder why Unix debuggers are so lame? It’s because if they had any functionality at all, they might have bugs, and if they had any bugs, they might dump core, and if they dump core, sploosh, there goes the core file from the application you were trying to debug. Sure would be nice if there was some way to let applications control how and when and where they dump core. The Bug Reliquary Unlike other operating systems, Unix enshrines its bugs as standard operating procedure. The most oft-cited reason that Unix bugs are not fixed is that such fixes would break existing programs. This is particularly ironic, considering that Unix programmers almost never consider upward compatibility when implementing new features. Thinking about these issues, Michael Tiemann came up with 10 reasons why Unix debuggers overwrite the existing “core” file when they them- selves dump core: Date: Thu, 17 Jan 91 10:28:11 PST From: Michael Tiemann tiemann@cygnus.com To: UNIX-HATERS Subject: Unix debuggers David Letterman’s top 10 weenie answers are: 10. It would break existing code. 9. It would require a change to the documentation. 8. It’s too hard to implement. 2Yes, under some versions of Unix you can attach a debugger to a running program, but you’ve still got to have a copy of the program with the symbols intact if you want to make any sense of it.

188 Programming 7. Why should the debugger do that? Why not write some “tool” that does it instead? 6. If the debugger dumps core, you should forget about debugging your application and debug the debugger. 5. It’s too hard to understand. 4. Where are the Twinkies? 3. Why fix things now? 2. Unix can’t do everything right. 1. What’s the problem? The statement “fixing bugs would break existing code” is a powerful excuse for Unix programmers who don’t want to fix bugs. But there might be a hidden agenda as well. More than breaking existing code, fixing bugs would require changing the Unix interface that zealots consider so simple and easy-to-understand. That this interface doesn’t work is irrelevant. But instead of buckling down and coming up with something better, or just fix- ing the existing bugs, Unix programmers chant the mantra that the Unix interface is Simple and Beautiful. Simple and Beautiful. Simple and Beau- tiful! (It’s got a nice ring to it, doesn’t it?) Unfortunately, programming around bugs is particularly heinous since it makes the buggy behavior part of the operating system specification. The longer you wait to fix a bug, the harder it becomes, because countless pro- grams that have the workaround now depend on the buggy behavior and will break if it is fixed. As a result, changing the operating system interface has an even higher cost since an unknown number of utility programs will need to be modified to handle the new, albeit correct, interface behavior. (This, in part, explains why programs like ls have so many different options to accomplish more-or-less the same thing, each with its own slight variation.) If you drop a frog into briskly boiling water it will immediately jump out. Boiling water is hot, you know. However, if you put a frog into cold water and slowly bring it to a boil, the frog won’t notice and will be boiled to death. The Unix interface is boiling over. The complete programming interface to input/output used to be open, close, read, and write. The addition of net- working was more fuel for the fire. Now there are at least five ways to send data on a file descriptor: write, writev, send, sendto, and sendmsg. Each involves a separate code path through the kernel, meaning there are five times as many opportunities for bugs and five different sets of performance characteristics to remember. The same holds true for reading data from a file descriptor (read, recv, recvfrom, and recvmsg). Dead frog.