If C is so evil why is it so successful?

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Apr 11 21:12:12 CDT 2017

    > From: John Wilson

    > It would have been nice if it had stolen FORTRAN-77's idea of declaring
    > a variable in the size that you want (I'm talking about INTEGER*2 vs.
    > INTEGER*4 etc.), instead of just "knowing" what the difference is
    > between int and long

Back in the late 70's, trying to write network code, even before we actually
ported anything (but could see it coming in the distance), it became clear
that C's type system was pretty worthless.

We defined a whole new type system, using syntax of the form 'XXXY', where
'XXX' was the type (unsigned, bit field, etc) and 'Y' was a character giving
the length (1, 2, 4, bytes; the machine's native word length - 'w'; etc,
etc). So 'bitw' was a bit-field of the machine's native word length, 'unss'
was a 16-bit unsigned, etc, etc.

So then we had an #include file "pdefs.h" which, depending on the setting of
'cc' -Dxxx command flags (this was before they starting getting set
automatically to indicate the machine type) included '11defs.h' or '68defs.h'
or whatever the case might be), so there were no #ifdef's in the source files
at all.

We used this everywhere, and it worked very well indeed.

So well that, at one point, on a dare, I moved our real-time OS to a new
architecture (the 29K) overnight (really - started at around 5PM one day, and
had it running the next day sometime - forget exactly when). Well, I'd already
gotten the debugger (written in C in the same style, with a bit of assembler
for the low-level operations) running on the 29K, so I knew where all the
pot-holes were, but still...

Most of the code modules were supposed to be portable .. and they just were.
Didn't have to touch it, just compiled for the new machine (so the exact same
source compiled for both, no ugly #ifdef's, just compile and go).

    > if it's not portable then it might as well be assembly and get the
    > benefits that come with that.

Sorry, I don't agree. It _is_ possible to write portable code, but even
ignoring that, the benfits of writing in a higher-level language (good
control structures, complex expressions, etc, etc) are well worth it.

I had the pleasure of working with the best MACRO-11 code I'e ever seen (a
real-time OS called 'MOS'), where the guy who wrote it (Jim Mathis) had worked
out a sdet of macro definitions that allowed him to define structures (and the
PDP-11 had an addressing mode, with a pointer to the base of the structure in
a register, that allowed you to access elements) - but even so, it wasn't as
good a tool as C.

Like I said, control structures, complex expressions etc all make things so
much clearer in C - which means they are easier to understand (when in someone
else's code), easier to debug, easier to modify, yadda-yadda. Unless I were
writing code that I _simply could not do in C_, I would not use assembler.


More information about the cctalk mailing list