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

41–50 of 155 posts

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

#41

Post by Unklejoe »

petra wrote: post #13
TickleSteve wrote: post #9

Earlier quoted context omitted.

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 ?

As said by TickleSteve, you define the worst case rather than analyze it.

As for the stack usage requirements, it seems like this could be determined statically by some parametric process, but I’m no expert on this.

Does anyone see a reason why there couldn’t be some algorithm to statically analyze some code to derive the worst case stack usage?

For example, take every function and assume that every variable declaration will be required. Add them up. Then, follow every path down the call tree while adding up the required stack for each call.

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

#42

Post by mk89 »

lambdadmitry wrote: post #30
pjmlp wrote: post #25

Earlier quoted context omitted.

Sadly quality is highly disregarded in our field. I dream of the day when not making use of contracts, static analysis and type based programming is seen as quality smell and not something that only a few are allowed to make use of.

It's not "disregarded", it's eclipsed by a need to ship often and ship a lot. There is a tendency to overstate amount of problems that come from bugs because they are painful to debug. Therefore, somewhat experienced programmers are often too defensive and suspect to paralysis by analysis (of which uber-complicated and rigid typing is a sort). Even if some advanced typing system will save a few days of debugging afte…

> ... it doesn't matter if a competitor ships buggy RoR-based systems a few months earlier.

You hit the nail on the head! However, I would like to mention that competition is only one very important factor.

I'd add that IT is a cost as it is a baker for a bakery, a cook for a restaurant, a mechanic for a repair shop. Do you want to be the n.1 restaurant? Then you must pay, so that your business is good food, not marketing - notice: the best restaurants don't even have good websites, as the food speaks for them. Yes, you must pay a lot to get the best cook, who will take all the time and require all the staff he wants/needs to prepare the best recipes, and so forth. We think we are in a better business just because IT is something relatively new, which not everyone fully understands, so we think that we are the best in everything we do, because we bring innovation. Sadly, we are not.

The current reality is that most companies are average or below-average with no great plans to further develop or to become the next IBM, NASA, Intel, or whatever. Most of them want to survive, some want to get a lot of money fast, and who knows, maybe in 5-10 years sell the company for 1,2,10 mln USD. As long as the mentality is driven by the idea of the acquisition, not by ambition, things won't change - the most efforts will be spent in hiding the pile of s* that employees do, trying to draw the right numbers on the right graphs. And even IBM, Nasa, Intel fail. They do. The difference lies in the ability to stand up and get on their feet again - learn from failures. They have also wasted huge amounts of money - it's documented everywhere, every time one of their projects gets shut down. However, they have a goal in their mind: to be the n.1 whatever they do.

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

#43

Post by icen »

kowdermeister wrote: post #39
sa1 wrote: post #31

Earlier quoted context omitted.

The https://en.wikipedia.org/wiki/Curry–Howard_correspondence says there is a correspondence between any logical statement and a type in a sufficiently advanced type system. So yes, there are languages aimed at eliminating logic errors, and Haskell goes pretty far(though its type system isn't quite advanced enough).

If I grasp that right, it says that if something is provable mathematically, then you can write a program for it with an equal meaning. I still don't see how that prevents user error. My question is then how do you mathematically prove intent? Also, how far should "sufficiently advanced" be? We already have a tool for that in the forms of unit tests and types does help if the subject is abstract enough.

An expressive and ergonomic type system goes a very long way into codifying that intent.

For example, it's quite obvious what the intent of this Idris function is: `f : Vect n (Vect m a) -> Vect m (Vect n a)` (where `Vect` is the type of lists of a given length).

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

#44

Post by titzer »

garethrees wrote: post #28

It looks to me as though the recommendation that RankRed has titled "Rule No. 5 — Low Assertion Density" would be better described as "High Assertion Density" — the recommendation is for a minimum of two assertions per function (and functions are supposed to be short per rule 4). The recommendations look good to me and (with one caveat) correspond to rules that I apply when writing C code with a high reliability requ…

Assertions in code cut both ways. Sometimes they can be great; telling you exactly which assumed invariant is violated. However, that doesn't tell you where or how the invariant was violated.

Sometimes assertions are just crutches for lazy programming. Instead of handling of a very valid (corner) case, some people just assert that it doesn't happen. Lo and behold, years later, it does happen. And those years later, the context is completely lost. How easy is it to handle the corner case now? Hard. In this situation, instead of simply asserting that it doesn't happen, it might be warranted to just assume that it _can_ happen and handle the case. Then, followed up with coverage testing, one needs to (actually try hard) come up with an input that triggers it.

Assertions can also have bugs. The worst is trying to figure out which assertions are really valuable and which aren't.

Shotgun-spraying assertions in the code is not a good strategy in general.

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

#46

Post by elcapitan »

corecoder wrote: post #21
elcapitan wrote: post #7

> Do not use [..] direct or indirect recursion. Ok.. I get it that they don't want their C programmers to do that, but do they also mean that this is to "complex" for normal developers to implement in a fault-free manner?

They mean that it's hard to write a static analysis tool that can determine if functions using recursion will ever terminate or not.

Just out of curiosity, why is that harder than writing a static analysis that determines if a loop with condition will finish?

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

#47

Post by brudgers »

thearn4 wrote: post #14

Speaking 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.

For me, I'd frame NASA's approach to software quality as a core value of the organization. The problem is that determining where a mission critical level of attention to detail is not necessary requires a mission critical approach because failure there means failure to develop mission critical code to support a mission critical function.

So the process of determining what does and does not require mission critical rigor has to be handled with mission critical rigor. Adding such a process is just one more point of failure. It requires the same attention as just writing the code "right" but is more subject to political maneuvering and other unproductive mental overhead and subjectivity.

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

#48

Post by gernerz »

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?

I cant speak for NASA, but in general if you are writing extremely safety critical code you simply don't use dynamically sized things. In addition to safety, the dynamically sized objects cause issues for the real-time constraints on these system as well.

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

#49

Post by robmccoll »

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?

#define MAX_NUM_OBJS 100

for(int i = 0; i Combined with the no dynamic allocation rule, you can guarantee that the number of elements in the array must be less than some maximum since you have limited dedicated space for storing them.

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

#50

Post by hackits »

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?

My take on it is. If have a task that can only allocate `once` a area of memory for initialization, then you can use the allocation size to put a constraint on the iterators based on the datatype size.

eg...

  const size_t taskSize = 256;
  const Task *task = (Task*) malloc(taskSize);
  zeroMemory(task,taskSize);

  // Allocate array of int's
  int *intPtr = (int*)(task);
  int intSize = taskSize+4;

  for (int i=0; i
Post reply on HN