Null pointers look simple on the surface, and that’s why they’re so dangerous. As compiler optimizations, intuitive but incorrect simplifications, and platform-specific quirks have piled on, the odds of making a wrong assumption have increased, leading to the proliferation of bugs and vulnerabilities.
This article explores common misconceptions about null pointers held by many programmers, starting with simple fallacies and working our way up to the weirdest cases. Some of them will be news only to beginners, while others may lead experts down the path of meticulous fact-checking. Without further ado, let’s dive in.
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.
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.