91–100 of 155 posts
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?
This is the reason why you see power of two limits in safety critical software. For example "radar is able to track up to 256 simultaneous objects".
for (i = 0; i Earlier quoted context omitted.
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?
Ignoring the time required to establish a new stackframe (versus a mere jump for a loop), the creation of a stack frame uses more memory. The less memory you can use, while still producing maintainable code, the better. And an easy way to assist with this is to remove recursion.
You could make the case for tail recursion, which a sufficiently advanced compiler will/can/should turn into a mere jump, like a loop, because it is. But this isn't guaranteed in the C standard and so should not be relied upon.
And then there's Rule #2. Loops are bounded, the index variable is supposed to only be altered by the loop structure (so: `for(i = 0; i only place `i` should be altered). By providing a compile-time max, and incrementing (deterministically) the index variable, you ensure that static analysis of the loop terminating (or not) is possible.
Earlier quoted context omitted.
Thanks! We updated the link from http://www.rankred.com/nasa-coding-rules .
I understand the need for linking to the original source, but I just looked at both and the latter is arguably harder to read.
The original paper isn't that terrible to read.
Also the amount of third party cookie crap that site tries to deposit in my browser is crazy.
That's why HN prefers source material, not blogspam stuff like this which adds nothing new and often removes possibly useful information.
This is a very interesting talk about writing the software for the Curiosity Mars mission by the head of Software Reliability at JPL, Gerard Holzmann, who also wrote these 10 rules: https://vimeo.com/84991949
> a function shouldn’t have more than 60 lines of code. I started having headache spikes after reading this sentence that refers to keeping functions "short", in the article about safety critical programs.
The fact that you could safisfy the business requirement with a single function of ~140LOC does not mean the other approach is more verbose, but that you are only thinking on the happy path, and a bunch of edge cases are left undefined.
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.
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 ) ?
Often a lot closer than in other languages, but that's still not close at all. And it depends a lot on how careful your code is. If you want to rely on the type system more heavily, you have to do more work upfront. E.g., using a simple SQL library that just takes queries as strings vs building your queries in a type-safe EDSL. You can write sketchy Haskell just like any other language, but you're likely to be much more aware of it.
>And how close are we to having that kind of capability for real-time programming?
Last time I looked it seemed like real-time Haskell still had a fair way to go. Presumably because it has garbage collection, lazy evaluation by default and other things that make it hard to prove time bounds. It can also be really hard to optimize sometimes IMO. But I doubt the features that make Haskell reliable are dependent on the features that don't suit real-time programs. I don't know of any pure functional languages with similar type systems, though. https://en.wikipedia.org/wiki/List_of_programming_languages_... has a pretty small list.
Earlier quoted context omitted.
#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.
There might not be a valid object at every location in the preallocated memory. Say you have a list of visible satellites, and the number of them can change as they go in/out of view. There's never more than 100, but sometimes there's 50 and sometimes 60. I supposed you could have an object with an INVALID flag, which the loop can use in its logic?
Recently there was a thread here where many argued against some company owner that has set the objective that the code created by his employees should be as simple as possible. Often the arguments boiled down to: It looks only clever if the skill level of your employees is too low, you should work on that. When I look now at the rules that NASA enforces, it seems to me that their objective is to prevent bugs by not a…
Complexity is an emergent phenomenon. It occurs when there are too many interactions to track. To make something simple is to take all of that complexity and to understand and model it as the interaction of a few simple rules repeated over and over and over.
Earlier quoted context omitted.
So, what is it, then?
what is a task/thread/process? where do I start.... a processor naturally has one thread of control, i.e. it executes instructions sequentially. To simulate multiple things happening at a time a context-switcher periodically saves and restores the current processor state and switches to another sequence. Each sequence is a thread-of-control... commonly known as a thread (or task, or process). ...and this isn't embedd…