Underlying C

A few months ago a friend directed me to an academic project, one that aimed to update C for the modern programmer. It’s not the first time people have done this—adding stuff to C is a time-honored practice.

All technology, as I am apt to repeat, is an imprint of a few core ideas. There are two of these ideas at the heart of C: unity with the underlying machine and the freedom to do anything that the machine can do. You can see these ideas expressed in many aspects of the language.

These days, if a language doesn’t have bitwise operators it’s deemed “incomplete,” but when I started programming, none of the major programming languages did. C has bitwise operators because the machine does. They’re in the opcodes of any processor.

C lacks the string data type. Theress the string constant, which initializes an array of characters to a display code constants. Comparisons, copying, and the like, are all done as function calls. All languages have to do these as function calls because modern computers lack a concept of strings at the machine code level.

C is meant to let the underlying machine shine through, and this turns out to be a very powerful concept.

Structures were common in underlying computers. In microprocessor assemblers we used EQU to define offsets from some index register. In the IBM System/370 assembler we even had something called “dummy sections” that let us use the ‘declare storage’ pseudo-operation to lay out a structure. That’s all just part of the machine.

Function prototypes were added to C eventually. When they were, Dennis Ritchie told me that they were long, long overdue. The checking for types got stronger over the years too. When I began with C, the following was legal C:

There are two of these ideas at the heart of C: unity with the underlying legal C:

0xffec->name

When the compiler saw the -> it knew it must add the structure member offset name to the value. That’s why there’s -> and . (dot). The first was required because the compiler didn’t keep track of types so it didn’t know if the left side was a pointer or not. As an aside, we also said =+ , =* , and so on, instead of += and *= i = i + 20 to i =+ 20. Unfortunately, i=-2 is a problem. Do we decrement i by 2 or assign it -2?

All that got fixed over the years, but there have been no real improvements since the 1989 standard. Checking wise, it’s as strictly type-checked as it can get and remain C.

As to the occasional research projects that work to “update” C, I suspect there is a lack of understanding of the relationship between what the machine does and C’s core ideas. Sometimes I hear whispers about “the death of C.” This is largely exaggerated. Almost all the operating systems are still being written in it. It’s still mentioned on the internet more than any language other than Java, which has a history of swapping number one and two spots.

C isn’t going anywhere.