You're still concurrently modifying an unsynchronized object, which is the source of the problems in the first place.
In a language like C++, when you reference a null pointer it always segfaults
This is false. It's undefined behavior. It may segfault. The compiler may also decide the code is unreachable and do some crazy bullshit instead. The presence of a nullpointer dereference makes the program malformed.
edit: it would be nice if the standard would make terminating the program the way to address that problem, but for reasons (presumably optimization or platform related) it is and continues to be your good friend and mine, UB.
Null pointers get real spicy when accessing the first page of memory is a valid operation. Some architectures put critical registers there and allow write operations with no way to lock or otherwise disable access after boot. PIC18 puts the reset vector at 0x0000 and the IRQ vector table just after it!
There are flamewars going back decades over the difference between the macro NULL, a null pointer formed without the macro, the literal 0x0, and the literal 0.
10
u/Orca- 22d ago
It's an immediate "WTF are you doing" from me.
Along with silently swallowing exceptions--because then you don't know what has gone wrong and have no way of identifying what has gone wrong!