[pcwalton]

Just that Rust is known for its borrow checker doesn't mean that the borrow checker is the only type of safety that Rust offers. The old standbys are still valuable: bounds checks, null pointers, compile-time data race detection.

> Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.

I find that I can develop software faster with Rust than with C, simply because of language and standard library features: closures, iterators, a real string library, a vector type, hash tables in libstd, better unit testing support, etc. Development speed can affect time to market.

As the industry matures, though, reliability generally becomes more important. And "embedded" covers everything from IoT light bulbs (correctness less important…for now) to avionics (correctness extremely important).

[shaklee3]

You should be comparing to c++ and not c, since if you are looking for those features, you'll find them.

[reificator]

Embedded systems typically doesn't use C++ either. I think it's still a fair comparison.

[andromeduck]

In my experience is usually a mix of both.

[throwaway84742]

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.

[unwind]

This is not true at all.

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.

[ratmice]

even worse, there might be something there like the exception vector table, in which case spurious writes become an attack vector.

https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf

[throwaway84742]

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.

[rvense]

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.

[throwaway84742]

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.

[arcticbull]

In many ways I would say a non-faulting non-protected read or write from 0x0 is worse than a crashing protected read.

[gmueckl]

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.

[arcticbull]

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.

[gmueckl]

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.

[arcticbull]

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.

[icedchai]

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.