Dynamic memory allocation - rule 20.4

[mroczeks]

Hi,

I missed discussion about new Misra C to be released.
Anyway now and then I have several questions and comments about dynamic memory allocation.

In Misra C 2004 there is only one rule (20.4) addressing dynamic memory allocation.
In my opinion it's too little. There are questions not answered by this single rule.

So the questions are:
1. Is this rule only forbiding use of malloc, calloc, realloc and free functions while leaving a room for implementation and use of prorpietary functions?

2. Is proprietary dynamic memory management allowed in any way?

3. I would like to implement my own "heap" (pool) which would allow for memory allocation on startup only and no deallocation anytime. Is this possible without violation of this rule?

In my opinion these questions should be answered in new Misra in some clearer way.

Best regards,
Szymon

[Lundin]

This would be one of the few cases where even the application-specific safety standard (i.e IEC 61508, DO-178B or whatever applies) most likely states an explicit ban for a certain programming practice. Dynamic memory allocation of any form is banned in all forms of safety-critical programming, no matter programming language. Though perhaps a clarification of the MISRA rule would be good regardless.

[mtempest]

As I understand it, all of the options you proposed would violate the rule 20.4.
The rule precludes all dynamic memory allocation, and not just specific functions. It therefore also precludes a custom/proprietary implementation.

However, the MISRA rules take into account that sometimes rules will have to be broken - see the "Deviation procedure" section in MISRA-C:2004. You then carry the burden of convincing QA/auditors/certification authorities/whatever that you have understood and addressed all relevant issues. (You have to do that anyway - complying with the MISRA rules is one (good) way towards achieving this.)

Depending on the specific nature of your system and your particular requirements, you may perhaps be able to motivate your 3rd option (dynamic memory allocation permitted only during startup, no deallocation whatsoever), even though it does violate rule 20.4. It would appear that the memory-management approach you are suggesting has been used before. See, for example, the second paragraph in 2.1 on page 9 of http://www.adacore.com/uploads/technical...s_GNAT.pdf
(I am not affiliated in any way with Adacore or VxWorks, and I am not advocating the use of either of their products or services.)

Michael

[mroczeks]

Thanks a lot for your replies.

I'm still in doubt. Mainly because Rule 20.4 belongs to 6.20 Standard Libraries part and also text of this rule references to standard functions vastly. It's like strongly indicating that it's about standard functions and it just very unclearly indicates that this is also about any other dynamic memory allocation approaches.
Anyway it seems that formal Deviation procedure is the best way in this situation.

Thanks again,
Szymon

[misra-c]

For MC:2004 the headline rule is unambiguous - dynamic allocation shall not be used.

This applies to the standard library functions [malloc(), free(), etc] but also to any user-defined equivalent functions.

Should you choose to Deviate then it is up to you to justify that decision.