Dynamic memory allocation using malloc()/calloc()

[raveendran]

Hi,

I have a few queries with respect to \"dynamic memory allocation\". As per the rule we are not supposed to use functions like \"malloc()\", \"free()\", \"calloc()\" etc. But malloc() is a very common requirement. Most of the embedded system applications use their own application level memory managers so as to make the allocation and de-allocation fast. Do you have any suggestions to get around this problem ( if we can't use malloc, any other way )?

One possible solution I can think of right now it to do a static allocation of a big chunk of memory and redirecting all the dynamic memory requirements to that chunk ( basically a kind of memory manager ). But here also we are stuck with one problem. If we write an application level memory manager, it has to cater to all data types. This will require conversion from any data type to \"void*\" and from \"void*\" to any data type ( say \"char*\" ). But Rule No: 45 of MISRA C ( Typecasting from any type to or from pointers shall not be used ) prohibits me doing that also.

The third problem is with writing portable code. Its quite common to use codes like (X*)0->data1 to get the offset to data1 , where X is a structure ( struct X { }; ) and data1 is a member within that structure. Are we not supposed to use these types of casts too [ (X*)0 ] ???

It would be great if someone could give some possible solutions to these kind of issues.

- Thanks
- Raveendran V.

[MISRA Reply]

This question raises a more general point.

We have been asked about solutions and workarounds for various things that are prohibited in both MISRA C1 and MISRA C2 such as using malloc, calloc, etc. for dynamic memory allocation.

Neither MISRA or any member of the MISRA C Working Group will give any guidance or approval to any deviation or \"workaround\". Any advice that may be given by any individuals associated with MISRA C is entirely personal and is not to be seen as a comment from MISRA or the MISRA C Working Group. In general the advice we would give is:

Where you have decided it is not possible to comply with a rule you should raise a deviation giving your reasons and justifications for doing so. You will have to take documented responsibility for your own deviations.

Read Section 4 (of MISRA-C:2004) on using MISRA C, specifically section 4.3.2 on deviations which outlines how to use deviations.

In general deviations should be as local as possible and as specific as possible and must be subject to sign-off for each deviation (or class of deviation).

Remember YOU will have to take responsibility for your deviations.

[plieske]

Hi,
The third problem is with writing portable code. Its quite common to use codes like (X*)0->data1 to get the offset to data1 , where X is a structure ( struct X { }; ) and data1 is a member within that structure. Are we not supposed to use these types of casts too [ (X*)0 ] ???

Dear Ravenndran

Writing code that depends on knowing the offset of a member of a struct is already not really portable. There should be better solutions. By the way, dereferencing a NULL pointer is not ANSI compliant and might lead to surprises on some systems.

But I admit that if you HAVE to know the offset, it's an elegant way to compute it without declaring a variable of that struct type, and it works on most compilers. We also failed in our efforts to find a compliant way to compute the offset of a member.

Regards Roger