Very misleading writing style IMO. I would say most of their bullet points ARE actually true in most cases… they just keep bringing up somewhat rare/exotic exceptions as a way to call it a “falsehood”.
A claim which is mostly true is false. Programmers should pay attention to details, since that is all computers know.
Not everything can be easily boxed into Boolean categories so no, a mostly true claim is not simply false. You are erasing the key context and nuance to make this foolish absolute statement.
Details like the fact that people can have differing opinions and perspectives, and should not speak in absolutes?
Details such as that accepting the statement “a claim which is mostly true is false” means that “a claim which is mostly false is true” must also be accepted (that one, or “a claim which is sometimes true is true” depending on what you think “not (mostly true)” means) :)
Before virtual memory was a thing, almost all memory was accessible.
Virtual memory has nothing to do with whether 0 is a valid address. You can have a CPU where it is valid, or one where it isn’t and you’ll get an access fault if you try to access it. You can also have virtual memory where page 0 is mappable, or not.
I think the author knew that, based on the later points so it’s probably just bad wording. Interesting point about wasm too!
I read this, and thought it was kind of all over the place. Even the first “falsehood” about always immediately crashing is answered as “true for some languages but not some others”. Even the motion of superlatives in CS like “always” and “never” rarely hold, including this very sentence and almost certainly when talking about multiple programming languages.
And on that point, it’s a minor quibble, but while Go’s nil pointers are similar to C null pointers and Rust’s null raw pointers, it’s a strange thing to have the title be about falsehoods about null pointers.
But then much of the other supposed falsehoods are addressed only for the C language, such as null deference being UB or not.
- On platforms where the null pointer has address 0, C objects may not be placed at address 0.
I would like to see a ©itation [pun intended] for this being a supposed falsehood, since my understanding is that if an implementation uses 0x0 as the null pointer, then the check for a null pointer is to check if it’s equal to 0x0, which would require that no “thing” in C use that address.
I’m almost sure storing data at *(0) is undefined behavior, so yes, that falsity #9 is indeed false.
Also, many embedded toolsets expect you to write there.
Small nit:
CHERI is even weirder. CHERI pointers store 128-bit capabilities in addition to the 64-bit address we’re used to
The 128-bit capability (actually 129 since there’s a tag bit) includes the address. It’s 64-bit address + 64-bit metadata + 1-bit tag = 129-bit capability.
Macromedia Flash Action Script was the first language I saw that could have a RCE vulnerability caused by null pointer dereference.
Thank god HTML5 media killed Flash.
Flash isn’t dead yet.
I just had to use it to connect to an ancient Siemens building automation system. Luckily we’re replacing it this year.
FYI there is an open source reimplementation of Flash from scratch called Ruffle that should solve all the security issues that Flash had. It runs on WASM so it’s compatible with modern browsers. The New York Times is using it to bring back some old interactive/animated pages that relied on Flash.
Thanks, I’m going to have nightmares tonight.
