Dennis Ritchie is the designer of the C language and is the "R" in K&R, the nickname for The C Programming Language, co-authored by Brian Kernighan. He is a member of the Computing Science Research Center at AT&T Bell Laboratories in Murray Hill, New Jersey.
Dennis did his undergraduate and graduate work in physics and applied mathematics at Harvard University. Since joining Bell Lab's Computer Science Research Center in 1968, he has worked on the design of computer languages and operating systems. Along with others at Bell Labs, Dennis created the Unix operating system, and designed and implemented the C language. His current research is concerned with the structure of operating systems.
DDJ: As the designer of the C language, you are no doubt the world's very first C programmer in a world where the number of C programmers is inestimable and growing fast. Yet, certainly C was not your first language. When did your programming career begin and with what systems?
DR: I started when I was in college in 1961. I was a physics major. There was no such thing as a Computer Sciences curriculum then. The Comp Center at Harvard offered an informal course in programming on the Univac I, and I went to the IBM office and got manuals. In graduate school in 1963 I was the teaching fellow for the introductory programming course. For a while I worked at Project MAC at MIT. My graduate work was theoretical in recursive function theory. I lost interest in that aspect of things when I finished there, and I've been spending most of my time programming ever since.
DDJ: Do you actively program now?
DR: It depends what you mean by programming. There's a fair amount of looking at stuff and deciding how it should work. These days there's more bureaucratic stuff. I'm not in management, but I write memos, look at proposals, complain to the X3J11 C committee, and things like that. I'm definitely still involved in the technical aspects of things.
DDJ: The ANSI X3J11 committee has been five-plus years in arriving at a proposed standard for the C language. How long did it take you from the time you had your original idea for a C language until you had the first compiler running?
DR: The C language grew out of an earlier language. The syntax of the early C language was essentially that of B. Over the period of a couple of years it grew into something like its current form. The most significant milestone in the growth of the language was when the Unix system was rewritten in C.
DDJ: How long did that take?
DR: Mostly it was done in the summer. There were two tries at it. This was in 1973. The summer before, Ken Thompson tried to do it, and gave up. The single thing that made the difference was the addition of structures to the language. When he first tried there were no structures. They were in by the next summer, and this provided a way of encapsulating or describing the data structures within the operating system. Without that it was too much of a mess.
DDJ: You mentioned complaining to the ANSI X3J11 C committee. What was the extent of your participation in the development of the ANSI C standard?
DR: My participation in the committee was really quite minimal. I sent them a couple of letters. One was to point out the consequences and difficulties of the path they were taking with the new style function definitions and declarations. It's clear that the new style -- function prototypes, as they call them -- is a good thing. The language is better for having it, and it should have been done that way the first time. The problem, however, is in the interval before prototypes are universally accepted, while you still have both the old and new styles. I pointed out that with that approach there will be confusion and the possibility of errors. For example, if you think that there's a prototype in scope, you might call the function and expect that the arguments are going to be coerced as they would be in regular ANSI C. But it might not happen.
DDJ: In the Rationale document, X3J11 has paved the way to eventually do away with the old style of function declarations and definitions. Will that solve the problem?
DR: Yes, but in this interval there is a sticky situation. There are complicated rules for what happens when you mix the new and old styles. They covered all the bases when they made the rules, but the rules are messy, and most people couldn't reproduce them or explain what they mean. The letter I wrote was to suggest that maybe they should think about not doing it if only because it's too late, or as an alternative they should consider requiring an ANSI compiler to have the new style only.
My second letter was related to this "no alias" business that came up about a year and a half ago. I felt more strongly about this issue because I felt they were about to make a bad mistake, and I was willing to spend a lot of time getting them to reverse it.
Around December 1987, when they were intending to produce the penultimate draft, the one that had all the technical things in it (with possibly some language polishing needed, but nothing important), something that had been simmering a long time came to the boil. Some people wanted to put in a mechanism that would reduce the problems that optimizers have with aliasing.
Here's the problem. Suppose you have a single function that has two pointers as arguments, and the function can never be sure that the pointers might not point to the same thing. Or, suppose one of the pointers points to some external place. The function cannot tell where the pointers are going to clash. According to the language rules, this kind of thing is possible, and optimizers have to be very conservative about it. In most functions it might never happen, and so the conservative compiler will generate worse code than it would otherwise. Languages such as Fortran have an easier job of this because such aliasing is simply forbidden. There's no enforcement, of course, but the compiler can take an optimistic point of view. If your program doesn't work, someone can pull out the standard and say you shouldn't have done that. Aliasing was a plausible thing for the committee to think about. It does, in fact, make C somewhat harder to optimize. The mistake they made was in trying to design a facility to allow the programmer to say that a particular function has no aliasing problem. But they actually blew it. The language rules that they developed, even after many sessions of hard work, really just weren't correct. Their specification for how you say "no alias" was broken and would have been much more dangerous than not having it. If this had happened three or four years ago, people would have seen that this was wrong, fiddled with it, and either thrown it out or fixed it one way or the other. But this was supposed to be the next to the last draft, and all the technical requirements were supposed to be already done, and it was just broken.
That December I drafted a long and strongly worded letter to them saying that this just won't do, and pointed out the problems that I'd found. I even went to the meeting, the first X3J11 meeting I'd been to, and argued against it. What got me worried and annoyed was that this had happened when it did. If the thing had gone ahead it would have been a real bug in the specification. On the other hand, fixing it essentially meant a technical change, an important, non-editorial change, and they would need another long public review period. The point of view that I advanced was to get rid of it. I figured that my argument had to be simple to understand. If I had said, "This 'no alias' is broken, here's another thing that you should do instead," I could see us getting bogged down endlessly worrying about the technical details, so I figured it was better to argue that they should just throw it out altogether.
That was the only really detailed involvement I had with X3J11. The outcome was that there is no specification for "no alias." They voted it out. Except for some slight fiddles, the draft that is now before X3 is technically identical to what it was nearly two years ago.
Aside from those two issues, I left them alone for two reasons. One is that to take part in a standardization effort is an enormous amount of work. There are three one-week meetings a year all over the world, a lot of detailed reading, and I really didn't have the heart to do that. The second reason is that it became clear early in the proceedings that the committee was on the right track themselves. Their charter was to codify and to standardize the language as it existed. They decided in advance to do that and that is what they did. They did add some new things. The function prototypes are by far the most obvious, and there are a lot more minor things, but mainly they stuck to their charter.
I think they did a very good job, particularly when compared to the things that are happening in the Fortran committee, X3J3, where there are wide swings back and forth about the strange new things they're adding in, taking out, and putting back in. They have great political arguments between customers and vendors, Europeans versus North Americans, and it really seems to be a free-for-all. Even though some wrangling went on in the C committee, with the people involved seeming fairly fierce when you looked at it from outside, it's obvious that X3J11 was a comparatively tranquil and technically wise group.
The upshot is that I think they did a good job. Certainly, though, if I'd continued to work on things, some of the details would have been different.
DDJ: Are there any major areas where you disagree with the standard as it exists now?
DR: There are some obvious weaknesses. For example, they have never worked out what const really means. One of its intents is to say that this is some data that can be put into some read-only storage because it's never going to be modified. The definition that they have now is sufficient for that. But they also had other ideas about what it should mean, having to do with optimization, for example. The hope was that const is somehow a promise that the compiler could assume that the data item wouldn't change underfoot.
If you have a pointer to a const, one might hope that what is const is not going to suddenly change secretly. But, unfortunately, the way the rules read that's not actually true. It can change, and this wasn't just an oversight. In fact, they are potentially overloading the meaning of const. There are ideas involved other than what people hoped to get, and they never really worked out exactly which ones they wanted and which ones they didn't want. It's a little confusing.
It's generally recognized that the standardization of the library was as important as the standardization of the language. Among Unix systems there are few variations on what's available in the library. Most things are pretty much the same. In recent years, the use of C has spread far outside of Unix systems, and the libraries supplied with compilers tend to vary a lot, although many of them were based on what was available on Unix. So the standardization of the library is important. On the other hand, I've heard lots of complaints, both from users and implementors, that what they standardized and some of the rules and interfaces for library routines were not very well worked out. There may be more there than is necessary. Things got too complicated.
