MISRA C advises against malloc, does this mean calloc is far more secure?

Question

I have used C for a few years but only recently made a serious effort to understand undefined behaviour and the pitfalls of C memory leaks etc. This is because now I use calloc several times in some code. The MISRA C recommendation is: Avoiding using functions and constructs that are prone to failure, for example, malloc may fail. I presume this means memory allocation could be a problem, does this mean calloc is secure? If not would this be advisable:

uint32_t *array;
        array = calloc(length, 32);

or is it just window dressing?

Thank you for any advice, I really want to avoid bad practise.

Answer 1

Any call can fail. If there is no memory to allocate, malloc will return null. If you don't check this return value, and provide suitable handling logic for an out of memory event, your program may crash. Often the only thing you can do is provide a message to the user about the situation.

If you are in a safety critical enviroment, where a software crash could lead to a car crash, this is very bad, hence for any loop involving the real time operation of an automobile, dynamic memory allocation is best avoided, as would be potential recursion.

window dressing in the form of calloc is not going to make any difference.

Answer 2

is it just window dressing?

Indeed it is. It doesn't matter if you use malloc or calloc (which does the same as malloc + initialization).

The key is checking the return value.

MISRA:

Avoiding using functions and constructs that are prone to failure

Taken out of context, this leaves someone who wants to do dynamic memory allocation with no other choice than to

1. Disregard the MISRA advice and just make sure every allocation is checked.
2. Make a big static allocation at program startup and use that as the only memory pool in the entire program. Provide proof that your program will never exceed the allocation made.

Answer 3

MISRA C is surprisingly brief when condemning malloc + friends. Dynamic allocation is a cardinal sin in all manner of safety-related applications and every other somewhat related standard out there bans it as well (IEC61508 + and the other "SIL" ones (trains, household appliances etc), ISO 26262, DO178, the JSF and NASA standards etc etc).

The potential error returned by malloc caused by running out of memory is probably the least problem with that function - because if you are running out of memory it means your whole program design is broken and that's no fault of malloc as such.

This Codidact post answers your question in detail, including the numerous severe problems with malloc and dynamic allocation in embedded systems:
Why should I not use dynamic memory allocation in embedded systems?

As for what can be used instead, safety-related applications use static sized buffers. Memory pools could be acceptable in some scenarios too, long as you have the error checking/handling there, check out my answer here.

Answer 4

The MISRA C recommendation is: Avoiding using functions and constructs that are prone to failure, for example, malloc may fail. I presume this means memory allocation could be a problem, does this mean calloc is secure?

MISRA C:2012 (and continued into :2023) is very clear:

• Directive D.4.12 - Dynamic memory allocation shall not be used

And if that is not enough:

• Rule 21.3 - The memory allocation and deallocation functions of <stdlib.h> shall not be used

In Rule 21.3, the amplification even lists the functions:

• calloc, malloc, realloc, aligned_alloc and free

So the simple answer to your question is: No, calloc is not OK if you wish to be MISRA C compliant.