4 ms·

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 valu

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 9y ago
You should be comparing to c++ and not c, since if you are looking for those features, you'll find them.
- reificator 9y ago
  Embedded systems typically doesn't use C++ either. I think it's still a fair comparison.
  - andromeduck 9y ago
    In my experience is usually a mix of both.
throwaway84742 9y ago
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 9y ago
  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.
  - throwaway84742 9y ago
    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.
  - ratmice 9y ago
    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 https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf
- arcticbull 9y ago
  In many ways I would say a non-faulting non-protected read or write from 0x0 is worse than a crashing protected read.
  - gmueckl 9y ago
    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 9y ago
      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 9y ago
        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.
- rvense 9y ago
  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 9y ago
    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.
- icedchai 9y ago
  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.

shaklee3 9y ago

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

reificator 9y ago
Embedded systems typically doesn't use C++ either. I think it's still a fair comparison.
- andromeduck 9y ago
  In my experience is usually a mix of both.

throwaway84742 9y ago

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 9y ago
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.
- throwaway84742 9y ago
  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.
- ratmice 9y ago
  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 https://cansecwest.com/slides07/Vector-Rewrite-Attack.pdf
arcticbull 9y ago
In many ways I would say a non-faulting non-protected read or write from 0x0 is worse than a crashing protected read.
- gmueckl 9y ago
  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 9y ago
    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 9y ago
      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.
rvense 9y ago
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 9y ago
  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.
icedchai 9y ago
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.