In 2003 I was somewhere south of Fort Worth, TX, having visited Dinosaur World, and shortly after leaving we stopped at a cafe that had three computers out which you could use. I looked at them while waiting for the coffee and they just seemed off, strange. It wasn't OS 9 nor X, it wasn't Windows... What was it? As I went over to look it hit me - holy cow, those are running that linux thing I've heard about! Their desktops were beautiful, totally different than the others. I knew then I wanted that.

Right, I'm not so much pushing back on you as I am establishing a chronology for CATB. Ordinary people were absolutely belting out (what we would now call) open source software by the time it was written.

(That's not the biggest flaw in the essay, of course. It made predictions, some of which turned out to be comically wrong. The true parts of it weren't new, and the new parts of it weren't true.)

HN is a common law system; the real guidelines are the guidelines page itself, and the "jurisprudence" of years and years of Dan (and Tom) writing moderator comments. But you also know you're a little off the rails when you've derived a rule that would prohibit, say, criticism of a book --- "Teach Yourself C In 24 Hours is a bad book". Of course that's OK!

But yeah, the big thing here is that the substance of my critique is on a different thread. It's disfavored to retype things you can just link to. I'd be irritated with me too if I just said "CATB is bad!" and left it at that.

It has nothing to do with NULL pointers and is instead a property of a programming language.

NULL pointers working the way they do was a design decision made my hardware engineers a long time ago because it saved some transistors when that mattered. We’re past that point now for most ASICs and hardware can be changed. Although backward software compatibility is a thing too.

[dead]

> Programmers like being able to null out a pointer field, 0 is an obvious "joker" value, and jump-if-0 instructions tend to be convenient and fast.

And there's nothing wrong with that! But you should write it

  union {
    char *ptr;
    size_t scalar;
  } my_nullable_pointer;
  if (my_nullable_pointer.scalar) {
    printf("%s", my_nullable_pointer.ptr);
  }

  char *my_nullable_pointer;
  if (my_nullable_pointer) {
    printf("%s", my_nullable_pointer);
  }

> The Hoare ALGOL W thing seems to be more relevant to null pointers in Java and the like.

I believe you are correct; but I like blaming Tony Hoare for things. He keeps scooping me: I come up with something cool, and then Tony Hoare goes and takes credit for it 50 years in the past. Who does he think he is, Euler?

The 68000 series used 0 as the initial (boot) program counter, and 4 as the initial stack pointer. (I might have those two backwards; it's been a long time.) That meant that they had to be in ROM, which meant that they were not writable. But addresses 8 through 1K were the interrupt vector table, and they did have to be writable.

This led to strange hardware implementations like "0 and 4 point to 0x800000 and 0x800004 (or wherever the ROM is) until a latch is cleared, then they point to 0" - with the latch being cleared fairly early in the boot process. This let you create a different entry point for soft and hard boot, if you wanted.

In that implementation, you could read and write to 0, once the latch was cleared.

Or you could have an implementation where 0 and 4 pointed to ROM always, and you could not have a different entry point for soft boot, and you could not write to 0, ever.

Skimming appendix H of https://courses.grainger.illinois.edu/cs423/sp2011/lectures/..., I can't see any special treatment of the zero page, but https://stackoverflow.com/a/22847758/5223757 contains an anecdote about SPARCs not placing a page of zeroes at that address. I expect that's probably an OS restriction, and they considered it safer to modify the in-house software they understood, rather than tinker with the externally-sourced OS's memory management routines, but the anecdote is weak evidence that it might have been a hardware distinction at one point.