[dahart]

No that's incorrect. Their rules are C guidelines, and they are easy to Google. You might want to do that before making assumptions.

NASA's rules, the ones being referenced above, are designed for safety. They require code to be easy to statically analyze and to have absolutely predictable behavior.

Also to be avoided: memory allocation, unbounded loops, function pointers, preprocessor macros.

https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

[danmg]

Most of the numerical code they're going to use is in Fortran, and interlanguage calling convention and the runtime might pose a problem.

This is in addition to not using recursive functions being pretty standard in anything embedded. Early computers and embedded systems had very limited stack space or had calling conventions that made recursion impossible.

[dahart]

> Most of the numerical code they're going to use is in Fortran, and interlanguage calling convention and the runtime might pose a problem.

The rationale they used for these rules was written down. It has nothing to do with Fortran. I've offered links that you can read. You're making more assumptions. If there's C-to-Fortran calling at all, then recursion presents zero extra difficulty. Once you can make any function call, you can make all function calls.

> This is in addition to not using recursive functions being pretty standard in anything embedded.

It's true that for small embedded devices, recursion is not used often. It's also true that function pointers and heap allocations and unbounded loops are generally avoided too. Though, often main() in an embed is a white(true){} loop. I wouldn't be surprised to see that at NASA.

One could argue that all of these 10 NASA rules represent some standard practice in embedded code and/or some degree of common sense. They're not claiming to be new or non-standard or unintuitive or innovative; they simply wrote down what people agreed are best practices.