
JPL C Coding Standard [pdf] - c0rtex
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
======
narsil
> There shall be no direct or indirect use of recursive function calls.

> [The] absence of recursion prevents runaway code, and helps to secure
> predictable performance for all tasks.

I can see the reasoning here, but wow, banning recursion..

~~~
dahart
That sorta goes hand-in-hand with "There shall be no use of dynamic memory
allocation after task initialization." Which in my experience is the harder
rule to deal with. It's not that often that you really truly need recursion.
It happens, just not often. But no allocations, that radically changes how one
codes.

But, these rules are for safety on embedded systems with very small amounts of
memory. These represent the best lessons learned, the best ways to guarantee
your function will finish in finite time and not run out of memory.

~~~
fsloth
"But no allocations, that radically changes how one codes."

But this does not forbid implementing ones own memory manager that uses blocks
from a huge continuous buffer.

~~~
dahart
True. Though I don't work at JPL or speak to what they would allow or forbid,
but if you did implement your own memory manager, I imagine that you'd still
need to write code that guarantees it will never run out, which might be
harder to do if you have this abstraction. The spirit of these rules is to be
enable code writing that is obviously correct and finite in time and space, at
a glance.

So I'm in pure speculation land here, but I could see JPL frowning on rolling
your own memory manager. Though I also imagine many applications of these
rules happen on hardware that is small enough to make writing a memory manager
overkill anyway.

------
alayne
[https://news.ycombinator.com/item?id=4339999](https://news.ycombinator.com/item?id=4339999)

------
c0rtex
Here's a great video with a bit more background about why you'd want to adopt
such a standard.

[https://www.usenix.org/conference/hotdep12/workshop-
program/...](https://www.usenix.org/conference/hotdep12/workshop-
program/presentation/holzmann)

------
nwmcsween
> The goto statement shall not be used...

> ...often results in improved code clarity

Um not really, if goto is used _right_ it clarifies code immensely.

~~~
alayne
They're avoiding the "not used right" problem in flight control software.

The full quote is "Simpler control flow translates into stronger capabilities
for both human and tool-based analysis and often results in improved code
clarity. Mission critical code should not just be arguably, but trivially
correct."

So there are reasons beyond code clarity.

Seems reasonable to me.

~~~
AbacusAvenger
Gotos _are_ trivial. They map directly to unconditional jumps at the assembly
level.

They're one of the best ways to implement exception handling in C (look at how
the Linux kernel uses them).

It's also not unusual to have conditionals that don't nest. Of course, if you
really want to avoid using a goto, you have the option of duplicating a lot of
code in order to satisfy all the code paths, decreasing readability and making
it harder to maintain. Or you can just use a goto and not worry about it.

I do understand _why_ people want to avoid 'goto', but Dijkstra wasn't always
right...

~~~
hyc_symas
I was at JPL when we were developing these standards. C was still pretty new
there, they used FORTRAN almost exclusively before that.

In practice, this rule had little impact. The only time you could justify
using a goto was for cleanup, and you could always end-run around the rule.

    
    
        ... blah blah ...
        if (error)
           goto fail;
        ... blah blah ...
        if (error)
           goto fail;
        ... blah blah ...
    
      fail:
        ... cleanup ...
    

just gets turned into

    
    
      do {
        ... blah blah ...
        if (error)
            break;
        ... blah blah ...
        if (error)
            break;
        ... etc...
      } while (0);
      if (error) {
        ... cleanup ...
      }

------
technion
>The JPL recommended static analyzers are fast, and produce sparse and
accurate messages.

I'm interested in what analyzers they may be recommending. I think this is a
field that's come a long way since 2009.

A lot of these standards could actually be implemented as rules in modern
products, which would assist with using them.

~~~
mturmon
The lead author of this standard is Gerard Holzmann, a Fellow of the ACM and a
member of the NAE. He works at JPL, and has been instrumental in introducing
code analysis to flight software (e.g., [http://lars-
lab.jpl.nasa.gov](http://lars-lab.jpl.nasa.gov)).

The analyzers JPL currently uses are Coverity, Semmle, CodeSonar, and
Klocwork. Coverity seems most common.

Of course, Gerard was an author of Spin
([http://spinroot.com/spin/whatispin.html](http://spinroot.com/spin/whatispin.html)).

------
dahart
It's lovely reading a coding standards document that is 100% focused on code
safety, and has zero stylistic argument.

These rules are a good reminder for me, too. A lot of them were habit when I
was doing C/C++ on game consoles. Using more dynamic scripting languages on
machines with more and more memory over the years has helped me forget. But
most, if not all, of these rules have valid analogues in any language that can
be aspired to.

------
Nickersf
Why were parts of the standard omitted? Money, national security, or both?

~~~
skissane
According to the document itself - copyright. LOC-5 and LOC-6 can't be
reproduced because they are copyright MISRA, and Appendix A can't be
reproduced because it is copyright ISO. Both documents are publicly available
to anyone willing to pay for them. So national security / government secrecy
doesn't appear to be a reason here.

------
ilogik
I was hoping there would be a mention of always using metric units.

------
pisipisipisi
Anyone happens to have a link to MISRA-C PDF ? :)

~~~
bionsuba
I hope you realize your asking people to publicly commit a crime. Not making
any value judgements, I just wanted to make sure you're aware.

~~~
DanBC
Breaking the law, sure, but crime? Simple copyright infrineent tends not to be
criminal. Other stuff is meeded - like selling the copyright material.

~~~
bionsuba
The colloquial use of the word crime means an action that breaks a law.

~~~
DanBC
No, the colloquial use doesn't include stuff for which you can't be punished
by the state. It's not a colloquialism, it's just an error.

