[throwaway37585]

> Then why does NASA consider it unsafe for mission critical code?

They also proscribe unbounded iterations (point 2). In any case, NASA’s guidelines for mission-critical code are not necessarily good guidelines for general software engineering, given the constraints involved.

It’s also worth noting that recursive solutions are probably more amenable to static analysis and automated theorem proving.

> How about unknown potential stack size?

If stack size is a problem, try an iterative solution.

> How about factoring a large number with recursion?

Go with iteration.

You keep editing your answer to add more cases where iteration is the way to go. I’m not disputing there are use cases where iteration is appropriate.

[danmg]

> Then why does NASA consider it unsafe for mission critical code?

More like they're using an old Fortran 77 environment which doesn't support recursive functions.

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

[throwaway344534]

More like they were using C, saw the prospect of unbounded stack calls unreasonable with a computer with limited ram and banned recursion. Oh wait that's exactly what happened because iteration is safer than recursion.

[dahart]

Iteration is not inherently safer than recursion. NASA also banned while(true) iteration. The important part is "fixed upper bounds".

"Give all loops a fixed upper bound. It must be trivially possible for a checking tool to prove statically that the loop cannot exceed a preset upper bound on the number of iterations. If a tool cannot prove the loop bound statically, the rule is considered violated."

https://pdfs.semanticscholar.org/ad40/26510beb1a309902704583...

[monocasa]

The static analysis tools have a harder time parsing the upper bounds on recursive functions, and so do the engineers doing the code reviews for similar reasons.

This isn't just a NASA thing. Pretty much any embedded coding standard says the same thing. The JSF C++ standard, and MISRA-C I know both do as well, just off the top of my head.