← Back to context

Comment by kibwen

1 day ago

Those guidelines are quite clear that they're written specifically in the context of the C programming language, and may not make sense in other contexts:

"For fairly pragmatic reasons, then, our coding rules primarily target C and attempt to optimize our ability to more thoroughly check the reliability of critical applications written in C."

A version of this document targeting, say, Ada would look quite different.

6 comments

kibwen

Reply
AlotOfReading  1 day ago

The JPL C rules are quite old, but avoiding dynamic allocation outside initialization is am considered best practice for spaceflight software regardless of language. Here's the recommendation from NASA's language-agnostic cFS:

    4.2.4 Consolidate Resource Allocations
    It is generally recommended to consolidate resource allocations to the application initialization function(s). Allocations and setup of resources such as memory pools and child tasks should happen once during initialization in order to provide more determinism during run time.

From: https://github.com/nasa/cFE/blob/main/docs/cFE%20Application...

The ESA Ada standard also recommends all allocation occur at initialization, and requires exceptions to be justified.

  • kibwen  1 day ago

    > The JPL C rules are quite old, but avoiding dynamic allocation outside initialization is am considered best practice for spaceflight software regardless of language.

    The rules are written with the historical context of C making it too easy to leak heap-allocated memory. In the safety-critical Rust code that I've worked on, we tend not to dynamically allocate due to the usual constraints, and we're well aware of the "thou shalt not allocate" rules in the scripture, but we've already gotten clearance from the relevant certification authorities that Rust is exempt from the restriction against dynamic allocation specifically because of its ownership system.

    • AlotOfReading  20 hours ago

      Even MISRA has rules allowing dynamic allocation these days. It's just a recommendation in most standards to make memory usage patterns easier to reason about.

    • uecker  11 hours ago

      This is scary, the issue in safe-critical code is not leaks (which Rust also does not necessarily prevent), but accidental resource exhaustion. This is also why JPL forbids recursion.

matklad  1 day ago

They do make a lot of sense in other contexts :-) From the actual rules, only #2 (minimize preprocessor) and #10 (compiler warnings) are C specific. Everything else is more-or-less universally applicable.