<![CDATA[MISRA Discussion Forums - 7.4 Code design]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:34 +0000 MyBB <![CDATA[Are Memory Pools allowed by MISRA-C?]]> https://forum.misra.org.uk/showthread.php?tid=1644 Tue, 14 Mar 2023 14:23:56 +0000 jpature]]> https://forum.misra.org.uk/showthread.php?tid=1644
Would a memory pool (to handle a variable number of objects) based on a statically allocated chunk of memory be MISRA C compliant ? Or would it be banned because considered as dynamic allocation ?

Thanks.]]>
Would a memory pool (to handle a variable number of objects) based on a statically allocated chunk of memory be MISRA C compliant ? Or would it be banned because considered as dynamic allocation ?

Thanks.]]> <![CDATA[Question about Dir 4.3 when a static function contains only variable declaration, asm and return statement]]> https://forum.misra.org.uk/showthread.php?tid=1493 Sat, 29 Jun 2019 09:39:30 +0000 chenzhuowansui]]> https://forum.misra.org.uk/showthread.php?tid=1493 Given the following case:
Code:
static inline uint32_t test(void)
{
    uint32_t tmp;

    __asm__ __volatile__(
        "mrc p15, 0, %0, c1, c0, 2\n\t"
        : "=r" (tmp)
        );

    return tmp;
}

i wonder if we could take the above case as compliant, as we cannot have variable declaration and return value in assembly. Thanks]]> Given the following case:
Code:
static inline uint32_t test(void)
{
    uint32_t tmp;

    __asm__ __volatile__(
        "mrc p15, 0, %0, c1, c0, 2\n\t"
        : "=r" (tmp)
        );

    return tmp;
}

i wonder if we could take the above case as compliant, as we cannot have variable declaration and return value in assembly. Thanks]]> <![CDATA[A question on Dir-4.9, in a case when a function-like macro and a function are not interchangeable.]]> https://forum.misra.org.uk/showthread.php?tid=1492 Fri, 21 Jun 2019 07:26:13 +0000 mz99]]> https://forum.misra.org.uk/showthread.php?tid=1492
Example 1:
-----------------------------------------------
#define ASSIGN( a, b ) ( ( a ) = ( b ) )
-----------------------------------------------

Example 2:
-----------------------------------------------
#define MACRO( a, b )

int32_t var1;
MACRO(var1,var2)
-----------------------------------------------

The macros are not interchangeable with functions,
because in Example 1, the arguments can't be modified if it is defined as a function,
and in Example 2, compile error occurs because var2 is not defined.]]>
Example 1:
-----------------------------------------------
#define ASSIGN( a, b ) ( ( a ) = ( b ) )
-----------------------------------------------

Example 2:
-----------------------------------------------
#define MACRO( a, b )

int32_t var1;
MACRO(var1,var2)
-----------------------------------------------

The macros are not interchangeable with functions,
because in Example 1, the arguments can't be modified if it is defined as a function,
and in Example 2, compile error occurs because var2 is not defined.]]> <![CDATA[Dir 4.14 - How to check pointer to structure]]> https://forum.misra.org.uk/showthread.php?tid=1471 Fri, 15 Feb 2019 07:52:33 +0000 apereira]]> https://forum.misra.org.uk/showthread.php?tid=1471
Code:
typedef struct myStruct{
    int myParam;
} myStruct;

void fcn(myStruct *const ptr)
{
    ptr->myParam = 1;
}

What is the recommended way to check the struct pointer in this function?]]>
Code:
typedef struct myStruct{
    int myParam;
} myStruct;

void fcn(myStruct *const ptr)
{
    ptr->myParam = 1;
}

What is the recommended way to check the struct pointer in this function?]]> <![CDATA[Dir 4.7 Unclear exactly what the critera is?]]> https://forum.misra.org.uk/showthread.php?tid=1465 Thu, 31 Jan 2019 18:57:20 +0000 chuck.cannon]]> https://forum.misra.org.uk/showthread.php?tid=1465
Is there any requirement on what is done once tested? For example, if there is no corrective action is it sufficient to just log the error?

Does returning the error to the caller qualify? In an API, the implementation of a API function may call subsequent functions that return an error. If only one such function is called then the only thing to do with the error is return it to the original caller.

err_t func1(void)
{
}

err_t func2(void)
{
return func1();
}

In our project, almost the entire code base running on the uC is a library exposed via an IPC link. All errors are just propagated back up and eventually sent back across the link to the caller.]]>
Is there any requirement on what is done once tested? For example, if there is no corrective action is it sufficient to just log the error?

Does returning the error to the caller qualify? In an API, the implementation of a API function may call subsequent functions that return an error. If only one such function is called then the only thing to do with the error is return it to the original caller.

err_t func1(void)
{
}

err_t func2(void)
{
return func1();
}

In our project, almost the entire code base running on the uC is a library exposed via an IPC link. All errors are just propagated back up and eventually sent back across the link to the caller.]]> <![CDATA[Dir 4.8 if struct is only visible through a function declaration]]> https://forum.misra.org.uk/showthread.php?tid=1452 Wed, 29 Aug 2018 12:22:47 +0000 LMende]]> https://forum.misra.org.uk/showthread.php?tid=1452 I humbly ask for help with compliance to Dir 4.8.
(Borrowing from cxlin, thx)
Code:
/* def.h */
struct SomeType
{
/* Object implementation */
}

/* other.h */
extern void usetype(someType* p);

/* no-use.c */
#include def.h
#include other.h
/* Do something. But no use of SomeType at all. */
Given a structure SomeType which implementation is visible to no-use.c.
A pointer to SomeType is only visible through the included other.h where the usetype function is declared.
Is the implementation of no-use.c compliant with Dir 4.8 or not?]]> I humbly ask for help with compliance to Dir 4.8.
(Borrowing from cxlin, thx)
Code:
/* def.h */
struct SomeType
{
/* Object implementation */
}

/* other.h */
extern void usetype(someType* p);

/* no-use.c */
#include def.h
#include other.h
/* Do something. But no use of SomeType at all. */
Given a structure SomeType which implementation is visible to no-use.c.
A pointer to SomeType is only visible through the included other.h where the usetype function is declared.
Is the implementation of no-use.c compliant with Dir 4.8 or not?]]> <![CDATA[Dir 4.10: Is a different form of the include guard considered a violation of the directive?]]> https://forum.misra.org.uk/showthread.php?tid=1411 Thu, 29 Mar 2018 12:36:57 +0000 GerlindeKettl]]> https://forum.misra.org.uk/showthread.php?tid=1411 header file being included more than once" says that in order to facilitate checking, the contents of the header should be protected from being included more than once using one of the following two forms:

Code:
#if !defined ( identifier )
#define identifier
/* Contents of file */
#endif



#ifndef identifier
#define identifier
/* Contents of file */
#endif
I got software from a third party which uses the first form, but the parentheses are a bit differently placed:

Code:
#if ( !defined identifier )
As I consider this include guard correct from a functional point of view, is this nevertheless a violation of Dir 4.10 because it does not use one of the two forms listed in the example?]]> header file being included more than once" says that in order to facilitate checking, the contents of the header should be protected from being included more than once using one of the following two forms:

Code:
#if !defined ( identifier )
#define identifier
/* Contents of file */
#endif



#ifndef identifier
#define identifier
/* Contents of file */
#endif
I got software from a third party which uses the first form, but the parentheses are a bit differently placed:

Code:
#if ( !defined identifier )
As I consider this include guard correct from a functional point of view, is this nevertheless a violation of Dir 4.10 because it does not use one of the two forms listed in the example?]]> <![CDATA[Dir 4.8 If no pointer is declared but implementation is visible]]> https://forum.misra.org.uk/showthread.php?tid=1410 Thu, 29 Mar 2018 11:11:25 +0000 cxlin]]> https://forum.misra.org.uk/showthread.php?tid=1410
/* def.h */
struct SomeType
{
/* Object implementation */
}

/* no-use.c */
#include def.h
/* Do something. But no use of SomeType at all. */

The example doesn't involve any pointer but indeed goes against the rationale since the implementation details of SomeType is not needed in no-use.c and it should at least be opaque. Also, logically, "no pointer" implies "a pointer is never dereferenced", since there is no such pointer to begin with.

Please kindly help to advise. Thanks!]]>
/* def.h */
struct SomeType
{
/* Object implementation */
}

/* no-use.c */
#include def.h
/* Do something. But no use of SomeType at all. */

The example doesn't involve any pointer but indeed goes against the rationale since the implementation details of SomeType is not needed in no-use.c and it should at least be opaque. Also, logically, "no pointer" implies "a pointer is never dereferenced", since there is no such pointer to begin with.

Please kindly help to advise. Thanks!]]> <![CDATA[Dir 4.6 and usage of "fast" types in stdint.h]]> https://forum.misra.org.uk/showthread.php?tid=1377 Thu, 12 Oct 2017 20:31:44 +0000 michael.metivier]]> https://forum.misra.org.uk/showthread.php?tid=1377
stdint.h also defines "fast" types which are at least of the indicated length, but may be larger if such a length could be handled more efficiently by the processor.

Is it a violation of Directive 4.6 to utilize these types? They are not "basic numerical types", but also do not necessarily adhere to a fixed length as specified by their names.]]>
stdint.h also defines "fast" types which are at least of the indicated length, but may be larger if such a length could be handled more efficiently by the processor.

Is it a violation of Directive 4.6 to utilize these types? They are not "basic numerical types", but also do not necessarily adhere to a fixed length as specified by their names.]]> <![CDATA[Valid typedef name rule for float/double data type]]> https://forum.misra.org.uk/showthread.php?tid=1351 Tue, 13 Jun 2017 07:17:44 +0000 Anitha Rajasekar]]> https://forum.misra.org.uk/showthread.php?tid=1351 typedef float UI_FLOAT_32.

It shows the warning for the above line of code as
1. misra_violation: [Advisory] MISRA C-2012 Directive 4.6 violation: typedefs that indicate size and signedness should be used in place of the basic float numerical type.

MISRA Violation
Typedefs Of Basic Types With Names That Do Not Indicate Size And Signedness
MISRA advises compliance with this rule.

The same issue is not coming if we use FLOAT32..
Is there any rule for the typedef name used for float and double.]]> typedef float UI_FLOAT_32.

It shows the warning for the above line of code as
1. misra_violation: [Advisory] MISRA C-2012 Directive 4.6 violation: typedefs that indicate size and signedness should be used in place of the basic float numerical type.

MISRA Violation
Typedefs Of Basic Types With Names That Do Not Indicate Size And Signedness
MISRA advises compliance with this rule.

The same issue is not coming if we use FLOAT32..
Is there any rule for the typedef name used for float and double.]]> <![CDATA[MISRA: Code Design (MISRA C-2012 Directive 4.6)]]> https://forum.misra.org.uk/showthread.php?tid=1350 Tue, 13 Jun 2017 06:48:52 +0000 Anitha Rajasekar]]> https://forum.misra.org.uk/showthread.php?tid=1350 void functionName(void)
{
}
It doesn't use any int data type. Even though it shows the below warning for this code
MISRA: Code Design (MISRA C-2012 Directive 4.6)
1. misra_violation: [Advisory] MISRA C-2012 Directive 4.6 violation: typedefs that indicate size and signedness should be used in place of the basic int numerical type.

Can anyone please help me to resolve this issue?]]> void functionName(void)
{
}
It doesn't use any int data type. Even though it shows the below warning for this code
MISRA: Code Design (MISRA C-2012 Directive 4.6)
1. misra_violation: [Advisory] MISRA C-2012 Directive 4.6 violation: typedefs that indicate size and signedness should be used in place of the basic int numerical type.

Can anyone please help me to resolve this issue?]]> <![CDATA[Interpretation of Dir 4.3]]> https://forum.misra.org.uk/showthread.php?tid=1307 Mon, 23 Jan 2017 06:45:08 +0000 nakagawat]]> https://forum.misra.org.uk/showthread.php?tid=1307
Would you please advise me if a macro containing both assembly and C code
is a violation of Dir 4.3?

Example:
#define M_def do { asm( "mv r0,r1" ); use_uint32( 0 ); } while( 0 )

Please note that 'use_uint32( 0 );' is a function call.

Regards,
Tad]]>
Would you please advise me if a macro containing both assembly and C code
is a violation of Dir 4.3?

Example:
#define M_def do { asm( "mv r0,r1" ); use_uint32( 0 ); } while( 0 )

Please note that 'use_uint32( 0 );' is a function call.

Regards,
Tad]]> <![CDATA[Directive 4.5]]> https://forum.misra.org.uk/showthread.php?tid=1270 Thu, 01 Sep 2016 11:59:35 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1270
please read the text carefully and then read MISRA C++ 2008 Rule 2-10-1.
It is virtually identical but in C++ it is rated required and in C it is rated advisory.
Was that a change on purpose or an accident?
Thanks.]]>
please read the text carefully and then read MISRA C++ 2008 Rule 2-10-1.
It is virtually identical but in C++ it is rated required and in C it is rated advisory.
Was that a change on purpose or an accident?
Thanks.]]> <![CDATA[How do I create a module in MISRAC:2012 that follows Dir 4.12 and 4.8?]]> https://forum.misra.org.uk/showthread.php?tid=1227 Thu, 18 Feb 2016 08:52:00 +0000 crisls1]]> https://forum.misra.org.uk/showthread.php?tid=1227 http://stackoverflow.com/questions/35341...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.


Module.h
Code:
/* 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;
Module.c
Code:
#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));
        }
User.c
Code:
#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.]]> http://stackoverflow.com/questions/35341...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.


Module.h
Code:
/* 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;
Module.c
Code:
#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));
        }
User.c
Code:
#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.]]> <![CDATA[Dir 4.8 2 struct pointers in a Translation unit]]> https://forum.misra.org.uk/showthread.php?tid=1145 Fri, 13 Feb 2015 09:46:25 +0000 misra-c]]> https://forum.misra.org.uk/showthread.php?tid=1145 File1.h
Code:
struct X { int32_t i1 };
  typedef struct X * ptrX;
  extern  void use_ptrX ( ptrX p );

File1.c
Code:
void fn ( ptrX a, ptrX b )
  {     /* no reference to a->i1 in translation unit  - does the type of "a" need to be opaque? */
     use_ptrX ( a );
     use_int32 ( b -> i1 ) ;
}
]]> File1.h
Code:
struct X { int32_t i1 };
  typedef struct X * ptrX;
  extern  void use_ptrX ( ptrX p );

File1.c
Code:
void fn ( ptrX a, ptrX b )
  {     /* no reference to a->i1 in translation unit  - does the type of "a" need to be opaque? */
     use_ptrX ( a );
     use_int32 ( b -> i1 ) ;
}
]]>