This is being re-posted approximately every two weeks. Why?
The Power of Ten – Rules for Developing Safety Critical Code
11–20 of 155 posts
Re: The Power of Ten – Rules for Developing Safety Critical Code
#12Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
What counts as a task?
task == thread of control.
(Seriously? downvoted because I gave a direct, true answer to a question?)
Re: The Power of Ten – Rules for Developing Safety Critical Code
#13Found the rule `There shall be no use of dynamic memory allocation after task initialization.` They must use pre-allocated string buffers for some of the task's. Though I figured if you're doing a flight controller for a jet fighter or sate-light you don't need a lot of string parsing.
dynamic memory allocation is very much frowned upon in embedded systems, not just for strings. Everything should be static and deterministic at all times. This is the easiest/only way to ensure you have no resource issues. You should always (statically) allocate for maximum/worst case.. because you have analysed your worst-case, haven't you?
How do you analyze worst case ? don't you need to know what calls what, up to what depth, and that's dynamic by nature ?
Re: The Power of Ten – Rules for Developing Safety Critical Code
#14Speaking from experience, the biggest problem with NASA's software engineering requirements (http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2B)
is the way that they tend to feed down into non-safety critical projects. It's getting better though.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#15All of these make perfect sense, but I would have allowed tail recursion (and only that). Its properties are well-defined and boundedness can be easily proven (also it is easy to distinguish tail and non-tail recursive calls).
They're using C. Many C compilers don't optimize tail recursion away, and even for those that do, it is not generally obvious from the C syntax whether something is a tail call or not.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#16This is being re-posted approximately every two weeks. Why?
And all of these are so obvious that it should be called 'undergraduate coding rules for any system'.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#17If we're talking about high reliability code, one thing claimed about Haskell, is "if it compiles, it has no bugs".
How close is it to the truth ? And how close are we to having that kind of capability for real-time programming(even assuming we're willing to forsake protability, community, and maximum efficiency to some extent ) ?
Re: The Power of Ten – Rules for Developing Safety Critical Code
#18If we're talking about high reliability code, one thing claimed about Haskell, is "if it compiles, it has no bugs". How close is it to the truth ? And how close are we to having that kind of capability for real-time programming(even assuming we're willing to forsake protability, community, and maximum efficiency to some extent ) ?
Haskell's type system protects from a certain class of bug, but it can't prevent logic errors - something like using won't trigger a build error, but it certainly is a bug.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#19Speaking from experience, the biggest problem with NASA's software engineering requirements ( http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2B ) is the way that they tend to feed down into non-safety critical projects. It's getting better though.
Having a look at the engineering requirements there are guidelines that I've seen that are used by medium to large scale organisation just simply to manage the project and code base.
Some of them seem to be universal such as statistic code analysis, heave use of sticking to a sub-set of the language that is well defined (Deterministic behavior). Sticking to a over-all coding convention and naming convention. Modulation of the code-base. Avoidance to thread's mutating the state of shared objects between threads (Share state between threads only in a single location eg.. IPC). Similar thing happened with java API with the designers attempting to make the language library thread safe. They soon discovered that was a real bad idea and backed off from that very fast.
At work I joke with my collegue's about the java framework they use they've now moved back to static enum's and static control id's for web pages instead of dynamically generating them on the fly. It's to a point where I feel like I'm programming win32 gui's all over again.
Re: The Power of Ten – Rules for Developing Safety Critical Code
#20If we're talking about high reliability code, one thing claimed about Haskell, is "if it compiles, it has no bugs". How close is it to the truth ? And how close are we to having that kind of capability for real-time programming(even assuming we're willing to forsake protability, community, and maximum efficiency to some extent ) ?
The stricter and more advanced a type system is, the more this comes close to the truth. Of course, no compiler can check that the function you implemented is the function you wanted to implement, but it can quite check that it can reliably compute the function you typed in.
The question hinges, on how much errors in your program express themselves as type errors too.