[TUHS] History of popularity of C
clemc at ccc.com
Thu May 28 01:09:43 AEST 2020
Henry Spencer's 10 Commandments for C Programmers
On Wed, May 27, 2020 at 10:38 AM Ronald Natalie <ron at ronnatalie.com> wrote:
> The large areas of undefined and unspecified behavior has always been an
> issue in C. It was somewhat acceptable when you were using it as a direct
> replacement for assembler,
> but Java and many of other follow-ons endevaored to be more
> portable/rigourous. Of course, you can write crap code in any language.
> It didn’t take modern C to do this. On the PDP-11 (at least not in split
> I/D mode), location zero for example contained a few assembler instructions
> (p&P6) which you could print out.
> Split I/D and VAX implementations made this even worse by putting a 0 at
> location 0. When we moved from the VAX to other processors we had
> location zero unmapped. For the
> first time, accessing a null pointer ended up trapping rather than either
> resulting in a null (or some random data). Eventually, we added a
> feature to the kernel called “Braindamanged
> Vax compatibility Mode” that restored the zero to location zero. This
> was enabled by a field we could poke into the a.out header because this was
> needed on things we didn’t have
> source code to (things we did we just fixed).
> Similar nonsense we found where the order that function args are evaluated
> was relied upon. The PDP-11, etc… evaluated them right-to-left because
> that’s how they had to push them
> on the stack for the call linkage. We had one machine that did that in
> the opposite order (I considered flipping the compiler behavior anyhow0 and
> when we got to the RISC architectures,
> things were passed in registered so the evaluation was less predictable.
> I already detailed the unportability problem I found where the BSD kernel
> “converted by union”.
> The most amusing thing I’d have to say was that one day I got a knock on
> my office door. One of the sales guys from our sister company wanted to
> know if I could write some Novell
> drivers for an encrypting ethernet card they were selling. The
> documentation for writing the driver was quite detailed but all describing
> i386 assembler interfaces (and the examples
> were in assembler). About a week into the project I came to realization
> that the linkages were all the C subroutine calls for that platform. The
> caller was C and there was no particular
> reason why the driver wasn’t also written in C.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS