Rules for Writing Safety Critical Code (2006)
spinroot.com
Rules for Writing Safety Critical Code (2006)
1–10 of 82 posts
Re: Rules for Writing Safety Critical Code (2006)
#2Nice.
These are reasoned, common sense measures, most of which I have seen in one form or another in the coding guidelines of the companies I have worked for as an embedded SW engineer.
Some of them are easy to enforce (no dynamic memory allocation, no recursion), other less so (using asserts, limit function size).
The worst is adding your rules-compliant code to messy and bloated legacy code :)
Re: Rules for Writing Safety Critical Code (2006)
#3An opinionated and needlessly specific list. For example, this
Use minimally two assertions per function on average
Assert your invariants
Do not use goto statements
Re: Rules for Writing Safety Critical Code (2006)
#4An opinionated and needlessly specific list. For example, this Use minimally two assertions per function on average should've been Assert your invariants And this Do not use goto statements is a controversial advice at best, because there are several well-established goto-based patterns that produce a much cleaner code.
> An opinionated and needlessly specific list
Not really. Gerard Holzmann is in charge of software at NASA/JPL. Each rule comes from experience with a mission loss that would have been prevented if people had implemented that rule. They also help static analysers become more accurate.
These rules are specific to ultra-reliable embedded software, flight software or software for life-critical equipment. They are not really relevant for most normal programming.
Re: Rules for Writing Safety Critical Code (2006)
#5An opinionated and needlessly specific list. For example, this Use minimally two assertions per function on average should've been Assert your invariants And this Do not use goto statements is a controversial advice at best, because there are several well-established goto-based patterns that produce a much cleaner code.
> An opinionated and needlessly specific list Not really. Gerard Holzmann is in charge of software at NASA/JPL. Each rule comes from experience with a mission loss that would have been prevented if people had implemented that rule. They also help static analysers become more accurate. These rules are specific to ultra-reliable embedded software, flight software or software for life-critical equipment. They are not re…
That doesn't mean that the rules are perfect. There haven't been that many mission losses to have a large corpus of data and finding a root cause of an accident might not lead to the best rules. "The rocket wouldn't have blown up if you asserted this here" doesn't mean that adding a large number assertions necessarily leads to better code.
Re: Rules for Writing Safety Critical Code (2006)
#6An opinionated and needlessly specific list. For example, this Use minimally two assertions per function on average should've been Assert your invariants And this Do not use goto statements is a controversial advice at best, because there are several well-established goto-based patterns that produce a much cleaner code.
I would also say perhaps
avoid recursion
avoid non-tail-call recursion
Re: Rules for Writing Safety Critical Code (2006)
#7Full 31 rules of NASA JPL C coding standard: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Previous discussion: https://news.ycombinator.com/item?id=4339999
Re: Rules for Writing Safety Critical Code (2006)
#8An opinionated and needlessly specific list. For example, this Use minimally two assertions per function on average should've been Assert your invariants And this Do not use goto statements is a controversial advice at best, because there are several well-established goto-based patterns that produce a much cleaner code.
> An opinionated and needlessly specific list Not really. Gerard Holzmann is in charge of software at NASA/JPL. Each rule comes from experience with a mission loss that would have been prevented if people had implemented that rule. They also help static analysers become more accurate. These rules are specific to ultra-reliable embedded software, flight software or software for life-critical equipment. They are not re…
Sure and this list likely worked well in the NASA/JBL context. The point being is it needlessly specific as a generic advice.
At the risk of stating the obvious, a "goto exit" pattern is the defacto standard for function cleanup in Linux kernel, which may not be flying every space probe, but it's still pretty damn ultra-reliable piece of software.
Re: Rules for Writing Safety Critical Code (2006)
#9These are fairly typical modern embedded s/w guidelines, safety critical code is much more rigorous specifically on the design & requirements side.
Re: Rules for Writing Safety Critical Code (2006)
#10An opinionated and needlessly specific list. For example, this Use minimally two assertions per function on average should've been Assert your invariants And this Do not use goto statements is a controversial advice at best, because there are several well-established goto-based patterns that produce a much cleaner code.
"An opinionated and needlessly specific list."
Opinionated, maybe (although it seems to me most rules are reasoned and a justification is given).
But something practical has to be specific.
It has happened time and again to come across something it appeared to me as an arbitrary an unnecessary rule, but with more experience I think it's better to have some "debatable" specific rules that something "open to interpretation", especially if many people will have to work on the same codebase.