3 ms·
The recent 2023 version of MISRA C costs just a few pound as PDF. So I got it from $WORK. I don't have a lot of experience with the previous versions. But the 2
by jpfr 3y ago
The recent 2023 version of MISRA C costs just a few pound as PDF. So I got it from $WORK.
I don't have a lot of experience with the previous versions. But the 2023 version reads quite okay.
It is not possible to mandate "though shall write good code" because it is not at all clear what that means.
Instead they needed to come up with rules that can be checked with automated tools.
The rules are classified as mandatory, required or advisory.
Only the mandatory rules cannot be overridden by explicit documentation.
As an example, "The goto statement SHOULD not be used" is an advisory rule.
Given the bad bad spaghetti code that beginner programmers produce with goto, this is quite reasonable.
Even though some code is definitely better with goto. For example to jump to some cleanup before returning.
Similarly, "A function SHOULD have a single point of exit at the end" is an advisory rule only.
The rationale for the rule stated in the standard is the following (slightly rephrased):
1. A single point of exit for a function is required by the IEC 61508 and ISO 26262 standards as part of the requirements for a modular approach.
2. Early returns may lead to the unintentional omission of function termination code.
3. If a function has exit points interspersed with statements that produce persistent side effects, it is not easy to determine which side effects will occur when the function is executed.
I'm also a big advocate for early return. But the points from the rationale are valid.
And I don't have a good alternative rule that achieves the same goal and is checkable with automated tools...
- 0x000xca0xfe 3y agoThat's the thing. The rationale sounds good. But where is the evidence? The code base followed all the rules, yet it was worse and had more bugs than any non-conformant code base I have ever seen. And teaching beginners to strictly follow rules instead of mercilessly rewriting and testing code until it is sufficiently clean and correct is the worst you can do, IMHO.
- jpfr 3y agoImagine how much worse the code would have been without all those rules. If people don’t have taste, no rules will get you to good code. Only a bit less worse / better predictable behavior.
- DaiPlusPlus 3y ago> Even though some code is definitely better with goto. For example to jump to some cleanup before returning. I’d have thought by-now that they’d be mandating dialects of C with try/finally instead of goto for error-handling.
- shiroiuma 3y agotry/finally is non-deterministic; that's why exceptions aren't allowed in DO-134b code. Here's an HN discussion about it: https://news.ycombinator.com/item?id=22483813 https://news.ycombinator.com/item?id=22483813
- DaiPlusPlus 3y agotry/finally in the context of thrown exceptions, sure. But in a language without exceptions (like portable C), we can alternatively define try/finally in terms of a "guaranteed execution" block no matter how control returns from a guarded try-block (be it `return`, `break`, `goto`, `longjmp`, etc). ...basically, a safer form of goto. It's possible to implement a form of this in portable C using only preprocessor macros, but it's messy and can't handle some cases, like longjmp.
- shiroiuma 3y agoI see, very interesting. Personally, I'd prefer to just have a "finally:" label; I've never liked "try", because it seems like extra boilerplate, and forces another level of indentation.
- DaiPlusPlus 3y agoI like how Swift did it: instead of try/finally, they have `defer`, which (when encountered) pushes a new clean-up task to the guaranteed-execution list in the right order: https://www.hackingwithswift.com/new-syntax-swift-2-defer https://www.hackingwithswift.com/new-syntax-swift-2-defer
- 3y ago