Right off the bat, disagree. I always bring up this example but it's actually expanded. On some embedded systems, there is RAM at 0x0. It is writeable and readable. On even more, there's ROM there. Countless times I've had a null pointer dereference be not only a silent failure that wreaks havoc downstream but also a valid operation.
In other times, I've had a malloc fail because I didn't have my heap setup, the code I had pulled in didn't check, and there goes my interrupt vector table or whatever.
When I was making a simulator for one of these chips I explicitly turned off that section of memory do I could catch null pointer dereferences. Not trivial to do in practice
+1 for this. On my system, an ARM cortex-M7, there’s RAM at address 0. In order to catch null pointer dereferences I ended up activating the MPU to make the first couple hundred bytes inaccessible (non-readable, non-writable).
MPU stuff is on my to-do list to get read up on. I have had a decent amount of stack overflows, the aforementioned example (which was on an M7), and other stuff that it might help with. It's something I don't necessarily want to rely on it in production, but it could help for debug.
In other times, I've had a malloc fail because I didn't have my heap setup, the code I had pulled in didn't check, and there goes my interrupt vector table or whatever.
When I was making a simulator for one of these chips I explicitly turned off that section of memory do I could catch null pointer dereferences. Not trivial to do in practice