Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Power of Ten – Rules for Developing Safety Critical Code

spinroot.com

Post reply on HN
Print view View original

141–150 of 155 posts

Re: The Power of Ten – Rules for Developing Safety Critical Code

#141

Post by AnimalMuppet »

lisper wrote: post #140
AnimalMuppet wrote: post #139

Earlier quoted context omitted.

> Does that qualify me to talk about these things? Yes, certainly. (Though I have been in embedded longer - 25 years. But you've been in safety-critical longer than me.) I must admit that I under-rated your experience. What part of the stuff from that link was written in Lisp? Was it just the planner, or also the exec? That is, did it have to be real time? And, in my previous reply, I asked a bunch of questions (besi…

> What part of the stuff from that link was written in Lisp? All of it. (Except for an IPC system which was written in C. See https://www.youtube.com/watch?v=_gZK0tW8EhQ if you want to know the whole story.) > Would you answer them? I'll answer a few of them. > if Lisp is so wonderful compared to C, how come so many more safety-critical systems are written in C? Politics mainly. And inertia. And the sunk cost fallacy…

> Politics mainly. And inertia. And the sunk cost fallacy.

I would say no, sort of, and maybe. I don't think I've ever seen a language chosen because of politics. For "inertia", I would say "conservatism" - people know that they can build systems (even safety critical ones) using C, and they know where the problems are. They don't know where the problems are using Lisp. And they don't want to take the time to learn Lisp - that's sunk cost, but whether it's a fallacy or not depends on whether Lisp really is more suited for such work than C. You assert that it is; many of us would like to see considerably more evidence before we agree.

What evidence? Maybe a few hundred hard real time systems successfully written in Lisp. (But how are we going to get them, if everybody defaults to C? I will grant you that there's a chicken-and-egg problem here...)

> > Is it because the entire profession is blind, and only you and a few enlightened ones realize how wonderful Lisp is?

> Yes. Pretty much.

Yeah... um... I think I'll just let your words speak for themselves.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#142

Post by cema »

davidgrenier wrote: post #38
cema wrote: post #37

Earlier quoted context omitted.

Type based programming does not quite work in weakly typed languages.

I think you should take what he said as saying we should get rid of those

Could be implied, of course. Still, there is a noticeable segment who think otherwise (eg a large portion of the Clojure community).

Re: The Power of Ten – Rules for Developing Safety Critical Code

#143

Post by safeignorance »

dragonwriter wrote: post #119
GregBuchholz wrote: post #114

Earlier quoted context omitted.

>The fly-by-wire flight software for the Saab Gripen (a lightweight >fighter) went a step further. It disallowed both subroutine calls and >backward branches, except for the one at the bottom of the main loop. >Control flow went forward only. Sometimes one piece of code had to leave >a note for a later piece telling it what to do, but this worked out well >for testing: all data was allocated statically, and monitorin…

If I read that article right, it sounds like the software fault attributed to the crash is that the "control laws" that the software implemented were improperly chosen, not that the software did not function as intended. Which is to say, a serious problem, but if we take "bug" to mean a difference between designed function and realized function, not a "bug", and therefore not something which should tarnish the record…

You're correct to point out that the coding style isn't to blame for the software fault. And IMO The last paragraph of the article hints at the most probable fundamental cause.

But I just don't buy that this was not a software fault. It clearly was a case of a faulty software specification.

> The problem seems to have been at a different level than coding.

This makes me queasy. Software engineers working on these sorts of systems -- -- or at least a few senior ones -- should understand enough of the domain to say "this spec is not adequate" or "bad things might happen under conditions xyz; what's the correct behavior in these cases?". And of course all software should notice and then degrade gracefully when assumptions are observably violated.

To absolve the software engineer of any responsibility for understanding the context surrounding his software is to wrongly assume there's not much to software engineering beyond programming to someone else's spec.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#144

Post by avindroth »

My first two years at undergrad would have been so much easier if I had read this piece of document.

I remember using a quadruple pointer (char ) in one of my systems classes.

Also, after having dabbled in Haskell, I know the value of static analyzers. That is like good practices on steroids. And you start to avoid these errors, and start developing better practices.

Change the environment to change your habits.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#145

Post by lisper »

AnimalMuppet wrote: post #141
lisper wrote: post #140

Earlier quoted context omitted.

> What part of the stuff from that link was written in Lisp? All of it. (Except for an IPC system which was written in C. See https://www.youtube.com/watch?v=_gZK0tW8EhQ if you want to know the whole story.) > Would you answer them? I'll answer a few of them. > if Lisp is so wonderful compared to C, how come so many more safety-critical systems are written in C? Politics mainly. And inertia. And the sunk cost fallacy…

> Politics mainly. And inertia. And the sunk cost fallacy. I would say no, sort of, and maybe. I don't think I've ever seen a language chosen because of politics. For "inertia", I would say "conservatism" - people know that they can build systems (even safety critical ones) using C, and they know where the problems are. They don't know where the problems are using Lisp. And they don't want to take the time to learn L…

> chicken-and-egg

Yep.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#146

Post by mapmap »

lordnacho wrote: post #45

How does that fixed upper bound on loops work? If there's an array of dynamic size that needs to be looped over, how do you do that?

Agreed, this puzzled me as well. I also have thought it was curious that we didn't get dynamically sized arrays in C until C99. Before that you had to malloc to the heap. It makes a little more sense now though having read this.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#147

Post by mapmap »

kowdermeister wrote: post #27
petra wrote: post #17

If 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 ) ?

I doubt that statement can be true in any programming language. Bugs come in many shapes and a functional language can prevent a fraction of it. You can have logic errors, misunderstood requirements, wrong database queries etc, the list is pretty much infinite.

I came here to read stories about floating point rounding errors and was surprised there is no mention of them. Maybe all failsafe code is done with integer math...

Re: The Power of Ten – Rules for Developing Safety Critical Code

#148

Post by dragonwriter »

safeignorance wrote: post #143
dragonwriter wrote: post #119

Earlier quoted context omitted.

If I read that article right, it sounds like the software fault attributed to the crash is that the "control laws" that the software implemented were improperly chosen, not that the software did not function as intended. Which is to say, a serious problem, but if we take "bug" to mean a difference between designed function and realized function, not a "bug", and therefore not something which should tarnish the record…

You're correct to point out that the coding style isn't to blame for the software fault. And IMO The last paragraph of the article hints at the most probable fundamental cause. But I just don't buy that this was not a software fault. It clearly was a case of a faulty software specification. > The problem seems to have been at a different level than coding. This makes me queasy. Software engineers working on these sor…

I absolutely see it as a software problem and a software engineering problem, just one orthogonal to considerations of the value of the coding style adopted in preventing code that deviated from specifications.

Re: The Power of Ten – Rules for Developing Safety Critical Code

#149

Post by fazkan »

I think the compiler is as much responsible for secure code as the code itself, tools should be updated regularly with these core concepts in mind...These 10 points, I figure are just the starting points, there are a lot of other places where the flow of program changed by abusing simple keywords such as volatile. Which is where the correct use of compiler, serve as a nightwatch to stop any undefined behavior from crossing the wall....

Re: The Power of Ten – Rules for Developing Safety Critical Code

#150

Post by thomaslee »

ranko wrote: post #2

The original paper describing and justifying these rules in more detail is at http://spinroot.com/gerard/pdf/P10.pdf , and the official document is at http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Any Debian users interested in Spin ought to be able to `apt-get install spin` sometime soon: https://tracker.debian.org/pkg/spin

It's already landed in unstable, testing shouldn't be too far away.

Post reply on HN