How do I create a module in MISRAC:2012 that follows Dir 4.12 and 4.8?

Moderators: misra-c, david ward

Post Reply
Posts: 1
Joined: Fri Feb 05, 2016 8:46 am
Company: ADASENS Automotive Innovation GmbH

How do I create a module in MISRAC:2012 that follows Dir 4.12 and 4.8?

Post by crisls1 » Thu Feb 18, 2016 8:52 am

I asked the following question on Stack Overflow and received a helpful answer which I have integrated into my question here. ( ... 12-and-4-8) The following is an extended version of the question I asked. This question relates to coding in ISO C99 following the MISRAC:2012 guidelines.

I am looking for guidance on Dir 4.8 “If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden” in conjunction with Dir 4.12 “Dynamic memory allocation shall not be used”.

When implementing an Abstract Data Type in C it is common to refer to the ADT using a handle that is a pointer to a structure describing the internal state of the ADT. This can be done using an opaque pointer as per Dir 4.8 with the benefit that the internal details remain hidden from the user.

Generally more than one of these ADTs could exist so there must be a way to create mulitple handles. This can be solved by allocating memory for the internal details referenced by the handle in an initialisation function, however, this is not allowed under Dir 4.12.

Another option is that the initialisation routine receives a pointer to a statically allocated handle provided by the user, however, this cannot be accomplished using opaque pointers.

I illustrate the problem below.


Code: Select all

       /* Module handle is only available to  the world as an incomplete type.
           This allows us to satisfy MISRAC 2012 Dir 4.8.*/
        struct module; 
        typedef struct module module_t; 

Code: Select all

        #include "module.h"
        struct module
            uint8_t value;
        module_t* module_get_a_handle(void)
             /* MISRAC 2012 Dir 4.12 disallows dynamic memory allocation.*/
             return (module_t*)malloc(sizeof(struct module)); 

Code: Select all

        #include "module.h"
        module_t* module_handle;
        module_handle = module_get_a_handle();
One solution is to use a statically allocated pool of handles within the ADT that are made available to client code. This solution seems to be technically compliant; however, it seems that the concept of dynamic memory allocation still exists here. I would argue that although the handles are statically allocated, it cannot be determined by the compiler during compilation whether there will be enough handles available for the software to function correctly.

I understand the argument that if a module runs out of statically allocated handles then it is a design error. However, it seems advantageous if the compiler can also determine in many cases whether there is enough space at compile time (this forces developers to fix the problem early rather than discovering it in code reviews or testing later on). The compiler can determine the problem if a statically allocated handle is passed from client code to the ADT as it is then clear to the compiler how many handles in total will be required by the SW. This also feels like a cleaner separation of concerns to me. Is it the responsibility of the ADT to know how many handles may be required, and if so does this not complicate any module reuse somewhat?

Additionally, in my case we are defining a company template that all new modules should be based on. The level of C proficiency of our developers ranges from beginner to intermediate. I am concerned that requiring each ADT to manage a static buffer of handles will be seen as overly complicated (and therefore a maintenance issue) and be met with resistance. Clearly raising the C skill level of developers is desirable but this will not happen immediately.

My solution to this problem would be to deviate on the advisory directive 4.8 and use non-opaque pointers and a strong naming convention that makes it clear to users that the internal details of the ADT must not be changed.

I am curious whether there is a well accepted method to solve this issue that satisfies Dir 4.8, and Dir 4.12, and does not break any other MISRAC:2012 rules. Is it common practice to define a static array of handles in every ADT?

I'm also interested in a critique of

a) deviating Dir 4.8 and using a naming convention that makes it obvious that the handle points to internal details that should not be accessed directly coupled with educating developers not to access the internals details.

b) deviating Dir 4.12(!) to allow dynamic memory allocation in a well defined initialisation phase only. For b), I believe that if it can be shown that the memory allocation is deterministic in this initialisation phase and the initialisation phase can be tested at a system level successfully once then it follows that the memory allocation will always be successful.

My preference is to deviate on the advisory directive 4.8 in this particular case as it seems to have the least disadvantages.

Any comments would be greatly appreciated.

Posts: 50
Joined: Fri Sep 17, 2004 10:53 pm
Company: Phaedrus Systems
Location: Phaedrus Systems Tamworth, UK

Re: How do I create a module in MISRAC:2012 that follows Dir 4.12 and 4.8?

Post by phaedsys » Tue Aug 16, 2016 2:37 pm

Whilst I expect the MISRA-WG will give clarification on MISRA-C rules they won't discuss code design. You might want to try the linked in MISRA-C&C++ Forum where there is discussion of this sort of thing by a lot of people who have a lot of knowledge of MISRA-C&C++
This post is made in a personal capacity
Member of MISRA-C-WG since 2002

Posts: 571
Joined: Thu Jan 05, 2006 1:11 pm

Re: How do I create a module in MISRAC:2012 that follows Dir 4.12 and 4.8?

Post by misra-c » Fri Aug 19, 2016 7:48 pm

The MISRA-C working group has read your question, but cannot give specific guidance on code design. We welcome the contributions of other MISRA users to this and all other Bulletin Board posts.
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “7.4 Code design”