I'm starting a new C/C++ embedded app and am trying to educate myself about safe coding practices like MISRA, AUTOSAR and my current favorite probably because it's the shortest, NASA's so-called Power of 10 (https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code). I can see the logic behind much of the rules. But all of them try to eliminate or restrict dynamic memory allocation. For example, MISRA C++ rule 18-4-1 says: “Dynamic heap memory allocation shall not be used” and NASA's rule 3 is "Avoid heap memory allocation". AUTOSAR is somewhat less restrictive. I understand their intent is to make sure a system doesn’t run out of memory but I'm not really clear about what a C or C++ compiler allocates as "dynamic heap memory allocation" or "heap memory allocation". I'll edit this post to ask specific questions
Thanks - Gene
Does that mean for example that all variables need to be static?
No, they can be local scope (automatic storage) too. If declared at file scope, they should generally be static (encouraged by MISRA-C and others).
Just to make sure I understand correctly, are temporary variables defined inside methods declared on the stack and therefore "safe" according to the MISRA, AUTOSAR and NASA guidelines?
Yes. Though you need to consider stack overflows, but that's another story.
"new” can’t be used after initialization according to the AUTOSAR and NASA guidelines?
Yes.
The C++ library array is OK according to the MISRA, AUTOSAR and NASA guidelines?
Not at all, there will be restrictions about which parts of the standard library you can use, particularly in MISRA-C++. There's a chapter in the MISRA guidelines stating rules for which headers that shouldn't used. These are pretty lax though, only banning the most crazy stuff like setjmp.h and misc hosted system stuff like signal.h.
For the higher levels of safety-critical systems, you'll eventually require that the standard libs themselves follow MISRA too, when possible. This is rarely ever the case, so mostly you'll try to stay clear of standard libs entirely.
But C++ libraries like string and vector can’t be used according to the AUTOSAR and NASA guidelines?
No they can't. C++ libraries in general are unsuitable for embedded systems. Personally I would never use C++ for anything remotely safety-critical and I have very bad experience from using C++ for embedded projects in general.
You can use it just fine, but it requires a lot from the C++ programmer, essentially you need to be fully aware of what parts that make a safe subset and which ones that doesn't and what assembly every C++ line results in. The average C++ programmer isn't skilled enough to do that, so if C++ is available, they will soon drag in dangerous or bloated features in the project.
In addition, the language has gone further haywire from C++11 and beyond, becoming increasingly unsuitable for embedded systems with more poorly-defined behavior, more rules for type punning and pointer aliasing etc. To document all cases of poorly-defined behavior in C++, you could fill a thick book.
Any other examples of "unsafe" dynamic memory allocation per the guidelines would be appreciated
Mostly it doesn't make any sense to use in embedded systems. If you know how a heap is implemented in a MCU, then common sense is sufficient to see why the heap doesn't fill any purpose. But also since dynamic allocation assumes that some manner of non-deterministic behavior is fine, which is never the case in safety-related software.
Regarding these NASA rules, they are quite shallow and naive. Most of them goes without saying and MISRA-C is far more in-depth. You can dismiss the NASA rules as beginner-level stuff: whoever came up in them as late as in 2006 seemed to have missed out all the research in the 1990s regarding developing safer subsets of C.
The silly rule about "no function pointers" for which NASA never managed a rationale was discussed here: State Machine with no function pointer.