I just wanted a place to share my thoughts about systems safety and reliability. Please consider everything in this forum to be random ideas, temporary, subject to changes, subject to refinements etc, also potentially going nowhere.
After spending the best part of a day fixing this issue, it turned out to be a missing stupid cast. It does not matter the level of experience, this kind of errors are bound to creep even into the best code-bases because the C language is intrinsically non secure.
C is not the best language for embedded, it has not even been specifically designed for embedded, it is just the only the current common for embedded programming. Other newer languages often make assumptions that make them unsuitable for bare metal programming, see garbage collection or other things requiring a substantial runtime.
C has one merit: it is an high level assembler requiring almost nothing as runtime. This is why it is the default choice for embedded.
Let's list the most common problems we all face daily:
- Race conditions, when you work with asynchronous events (IRQs) this is a real issue.
- Overflows, especially stack overflows.
- Types mixing freely.
- Mixing pointers freely.
This is nothing new, there are coding standards like MISRA that recognize the issues and try to address them, with very partial success, using static analysis methods and restrictions on the standard C.
If a language could address the above points then most problems would be fixed or caught at compile time. Let's call this hypothetical language "Safer C".
And C++? My opinion is that:
- It addresses none of the above concerns, probably it introduces more.
- Its (growing) complexity is a safety risk in itself.
- Its organization tends to hide details but also problems.
- C is complex enough, we need something simpler and safer, enhancements should not make the language harder or unsafer.
Please don't reply to topics marked with [NO REPLY], open new topics on specific points prefixing them with [DISCUSSION]. Ideas or changes will be integrated after the discussion.