So the case that you're making here is that CATB is renowned amongst the kind of practitioners who think NULL pointers are "just how the hardware works". Sounds about right.
I know you're replying to a brand new (likely troll) account, but I'm also very confused by this and would be curious to learn if there's any truth to it. I personally don't really see what a Von Neumann machine has to do with null pointers (or how an implication would go either way), but maybe I'm missing something.
No, the CPU doesn't have a special pointer value which is designated invalid (except as far as modern address spaces are so large that you cannot possibly map memory to each address without mirroring). In many OSs, e.g. CP/M, address 0 is actually meaningful. The C idiom of cramming sum-type semantics into the nooks and crannies of a return value that ordinarily means something entirely different is an extremely poor one, and null pointers are the poster child: Tony Hoare's billion-dollar mistake.
It's absolutely fine to have a packed representation of a sum type "under the hood": this is how Rust implements Option<&T> (where T: Thin), for example. It's also fine to expose the layout of this packed representation to the programmer, as C's union does. But it's a huge footgun to have unchecked casts as the default. If not for this terrible convention, C wouldn't have any unchecked implicit casts: something like f(1 + 0.5) performs a coercion, a far more sensible behaviour.
The only reason we're talking about null pointers at all is because they were an influential idea, not because they were a good idea. Likewise with the essay.
While it's narrowly true that CPU instruction sets generally don't have a null-pointer concept, I'm not sure how important that is: the null pointer seems to have been (I don't know enough to be sure) a well-established idiom in assembly programming which carried across naturally to BCPL and C. (In much the same way that record types were, apparently, a common assembly idiom long before they became particularly normal to have in HLLs.) 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. Whether or not you'd want to say it's "how the hardware works" it does seem to have a certain character of inevitability. Even if the Bell Research guys had disapproved of the idiom they would likely have had difficulty keeping it out of other people's C programs once C became popular. The Hoare ALGOL W thing seems to be more relevant to null pointers in Java and the like.
> No, the CPU doesn't have a special pointer value which is designated invalid
Sort of right, sort of wrong.
From my understanding: older, simpler, architectures treat memory location zero as a normal memory address. On x86 and x64, the OS can configure the MMU to treat certain pages as invalid. Many years ago, I ran across a reference to Sparcs treating accesses to memory location zero as invalid. In other words, it depends upon which architecture you're dealing with.
That's just how the hardware works. Don't like it? Make your own CPU.
So the case that you're making here is that CATB is renowned amongst the kind of practitioners who think NULL pointers are "just how the hardware works". Sounds about right.
I know you're replying to a brand new (likely troll) account, but I'm also very confused by this and would be curious to learn if there's any truth to it. I personally don't really see what a Von Neumann machine has to do with null pointers (or how an implication would go either way), but maybe I'm missing something.
4 replies →
[dead]
No, the CPU doesn't have a special pointer value which is designated invalid (except as far as modern address spaces are so large that you cannot possibly map memory to each address without mirroring). In many OSs, e.g. CP/M, address 0 is actually meaningful. The C idiom of cramming sum-type semantics into the nooks and crannies of a return value that ordinarily means something entirely different is an extremely poor one, and null pointers are the poster child: Tony Hoare's billion-dollar mistake.
It's absolutely fine to have a packed representation of a sum type "under the hood": this is how Rust implements Option<&T> (where T: Thin), for example. It's also fine to expose the layout of this packed representation to the programmer, as C's union does. But it's a huge footgun to have unchecked casts as the default. If not for this terrible convention, C wouldn't have any unchecked implicit casts: something like f(1 + 0.5) performs a coercion, a far more sensible behaviour.
The only reason we're talking about null pointers at all is because they were an influential idea, not because they were a good idea. Likewise with the essay.
While it's narrowly true that CPU instruction sets generally don't have a null-pointer concept, I'm not sure how important that is: the null pointer seems to have been (I don't know enough to be sure) a well-established idiom in assembly programming which carried across naturally to BCPL and C. (In much the same way that record types were, apparently, a common assembly idiom long before they became particularly normal to have in HLLs.) 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. Whether or not you'd want to say it's "how the hardware works" it does seem to have a certain character of inevitability. Even if the Bell Research guys had disapproved of the idiom they would likely have had difficulty keeping it out of other people's C programs once C became popular. The Hoare ALGOL W thing seems to be more relevant to null pointers in Java and the like.
1 reply →
> No, the CPU doesn't have a special pointer value which is designated invalid
Sort of right, sort of wrong.
From my understanding: older, simpler, architectures treat memory location zero as a normal memory address. On x86 and x64, the OS can configure the MMU to treat certain pages as invalid. Many years ago, I ran across a reference to Sparcs treating accesses to memory location zero as invalid. In other words, it depends upon which architecture you're dealing with.
2 replies →
They aren't there in asm.