Null pointer is actually perfectly fine on bare metal. There’s no memory protection, so it just points to address 0x0, and if you deref it nothing bad will happen.
First, of course, there is no requirement for NULL to map to address zero.
Second even if you do en uo there, many architectures don't even have memory at 0x0. Spurious writes are spurious writes regardless of whether or not you get a fault. You are still not doing what you want to be doing.
Ones I worked with did nothing on when reading from 0x0. I mentioned this because for someone who spends all their time well above bare metal this is not intuitive at all. And null is de-facto 0 on all C compilers, even though it’s not required to be. So let’s not engage in hyperbole here.
But it is never what you want. So even if there are no immediate explosions, your LED's not going to blink the way you expected it. I'd say a clear, stern sign that something was wrong is better than limping along after dereferencing null.
Sure. I’m just saying that null pointer deref and read is not generally a fatal operation. Most programmers expect the program to die in this case. When it doesn’t, they are surprised.
In many ways, generalized statements like this for all possible controllers and software out there are worse than understanding that accessing address 0 from high level code can have its uses and be completely correct. ;)
In a less condescending tone, if some HW designer put control structures at address 0 and they are writeable, then you have to deal with it in software. If there is no MMU that can remap that memory range, you will end up having legitimate memory accesses to that area. They can only be distinguished from accidental null pointer dereferences by context. This context would need to come from the developer by annotating the source somehow.
If the software is unintentionally reading or writing address zero, it’s by definition not functioning properly, but because of the lack of memory protection/safety this failure mode is going undetected. Rust won’t stop you from intentionally accessing 0x0.
This seems among the hardest bugs to track down I could think of, regardless of what is mapped at address zero. I don’t think it’s condescending to say software that begins operating incorrectly in an undetectable way is always bad.
Have you had to track one of these down before? I haven’t, But I have had to track down silent memory corruption issues in memory unsafe languages in the past and it can take days, on the desktop, with good tooling, I can’t imagine doing it on an embedded system.
If tracking down these kinds of errors on the desktop took you days, your tooling was maybe not good enough. I honestly cannot remember a an instance where valgrind completely failed me. This is lind of my gold standard for debugging memory issues.
Also, some microcontrollers have amazing debugging support these days. Instruction tracing on Cortex M devices is a great feature, for example. The CPU will log every instruction that it executes over a serial interface for the hardware debugger to store. This allows you to go back in time after the fact, something that desktop debuggers have a really hard time with.
My point is, with a language like Rust, you can pretty much throw all this away. Why put yourself through this intentionally?
I also feel you're dodging my question. A 1-in-1000 spurious write to 0x0 is something you'll have a terrible time even identifying as the cause of your failure specifically because it is completely silent. Your embedded system just happens to stop working sometimes, where do you even think to begin? Assuming you know this is why, sure, throw on a watchpoint and call it a day, but how did you connect "heater stops heating" to 1-in-1000 write to 0x0?
You don't have to worry about that with a language that wont even let you make that invalid program in the first place.
Well, this hasn't even been an issue for us in the last couple of years, even though we use controllers without MMUs. We have a quite complex C++ codebase and our coding style catches a lot of these mistakes outright.
Rust is simply not an option for us because of a distinct lack of tooling available for it. We need a ISO 61508 qualified toolchain including testing frameworks and there is none in sight for rust.
Also, out of interest: has anyone ever tried to write code in rust that is protected against bit flips caused by radiation? Our code is able to detect this because it stores long lived values also as bit inverted patterns and compares them regularly. This does not allow us to recover outright, but we can at least fail gracefully and attempt
to reboot the device.
I take it you didn't do much development on machines without memory protection. The problem isn't reading from 0x0. It's writing to 0x0 (and beyond), clobbering system memory , memory mapped IO, or even your own application.
I learned C on an Amiga, back in the late 80's. A bad pointer typically resulted in "Guru Meditation" error (OS crash), followed by a reboot.
First, of course, there is no requirement for NULL to map to address zero.
Second even if you do en uo there, many architectures don't even have memory at 0x0. Spurious writes are spurious writes regardless of whether or not you get a fault. You are still not doing what you want to be doing.