Welcome to the MISRA discussion forum

Hi,
Given the following case:

Is the use of the function-like macro compliant (shown in Example 1 and 2 below) with Dir-4.9, in a case when a function-like macro and a function are not interchangeable?

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.

Within MISRA Compliance 2016 it was cited the possibility to utilize possible deviation permits. However, unless wrong, since 2016 only the MISRA C:2004 deviation permits have been published, while no official deviation permits for MISRA C:2012 (am I wrong?). If this is confirmed, in case a given MISRA C:2004 rule, which is substantially confirmed also in MISRA C:2012, is associated to a deviation permit, can this latter also be applied/utilized in for MISRA C:2012?

MISRA C: 2012 Addendum 3 coverage to CERT C rule EXP47-C "Do not call va_arg with an argument of the incorrect type" is not defined.

I would consider that EXP47-C is covered by MISRA-C :2012 Rule 17.1

Is it correct ?

The word "object" is used in some rules of MISRA-C:2012. (e.g. Rule-8.9)
What is the definition of "object" in MISRA-C:2012?
Which of the following are considered as "object" in MISRA-C:2012?

• Variable

• Const-qualified variable

• Function

• Object-like macro

• Function-like macro

Rule 15.5 says:

Quote:When a return statement is used, it should be the final statement in the compound statement that forms the body of the function.

I recently downloaded MISRA C:2012, third edition, first revision, February 2019. The text for Rule 22.9 on page 190 says, "The value of errno shall be set to zero after calling an errno-setting-function" (emphasis mine). But the amplification, rationale, and exception all seem to deal with the testing of errno, not the setting of errno. The rule in Appendix A (on page 203) says, "..shall be tested against zero...", as does the version of the rule in the 2016 addendum. Seems like the text on page 190 probably needs to be fixed.

This new forum has been set up for asking questions about and discussing MISRA's "Guidelines for automotive safety arguments" (otherwise known as MISRA SC and MISRA Safety Cases).

The Working Group responsible for the MISRA SC document will consider questions posted here and if appropriate give an official response (which will be posted by the "MISRA Reply" user). Any other comments and responses from any posters shall not be considered an official MISRA position.

We expect to respond to questions on an approximately monthly basis so if you don't hear from us, please bear with us as we have day jobs to do too!

Hi,

I have a question about Rule 18-4-1 "Dynamic heap memory allocation shall not be used.".

C++ already has a form of memory allocation for its automatic variables.
That is they are allocated on the stack.
I take for granted that this form of memory allocation is allowed by MISRA.

Would managing and allocating the heap space in a stack fashion address most concerns associated with rule 18-4-1?

For example, the call stack is also subject to out-of-storage runtime failure, i.e. stack overflow.
The call stack being used to store a host of values associated with function calls and its depth may be based on runtime values.
The only way to secure against this being to find the worst case your system allows and set the stack size accordingly.

If the heap space allocator was not subject to:

• Memory leaks
  Non-deterministic behavior
  • Fragmentation
    Order of allocation/deallocation
    

Hi,
I have a question about Rule 5-0-15: "Array indexing shall be the only for of pointer arithmetic".

Is the rule satisfied if the code referencing the array element has no knowledge of the dimensions of the array object at compile/link time?

For example, in the case where the argument passed to parameter "p2" of "my_fn" is an array whose size is defined at runtime?