misra

I have a warning regarding Misra rule 19.7 : A function should be used in preference to a function-like macro in the below line : #define gOFFSETOF(type, mem) (gOFFSET)((size_t) ((char *)&((type *) 0)->mem - (char *)((type *) 0))) how should I solve this ? Rule 19.7 (advisory): A function should be used in preference to a function-like macro. While macros can provide a speed advantage over functions, functions provide a safer and more robust mechanism. This is particularly true with respect to the type checking of parameters, and the problem of function-like macros potentially evaluating

Why does MISRA recommends a inline function to be declared with static storage class? While the keyword inline is a hint to compiler to replace all function calls with actual function body and compiler may or may not perform it, how does giving a internal linkage (static) or external linkage (extern) to a function affect the inline operation by the compiler? MISRA C:2012 gives the rationale for rule 8.10 as: Rationale If an inline function is declared with external linkage but not defined in the same translation unit, the behaviour is undefined. A call to an inline function declared with

I have implemented a complex state machine with numerous state transitions for a safety SIL 4 system. The back bone for this implementation was done using function pointers. When all was sailing smoothly, the V&V opposed the use of function pointers in a SIL 4 system. Reference- Rule 9 NASA .Misra C 2004 however doesnt say that function pointers cant be used. Is there any other way to implement complex state machines without any function pointers? First of all, that NASA document is not canon. Start by asking which law/directive/standard/requirement/document that enforces you to follow the

I'm using IAR Workbench compiler with MISRA C:2004 checking on. The fragment is: #define UNS_32 unsigned int UNS_32 arg = 3U; UNS_32 converted_arg = (UNS_32) arg; /* Error line --> */ UNS_32 irq_source = (UNS_32)(1U << converted_arg); The MISRA error is: Error[Pm136]: illegal explicit conversion from underlying MISRA type "unsigned char" to "unsigned int" (MISRA C 2004 rule 10.3) I don't see any unsigned char in any of the code above. The discussion at Why did Misra throw an error here? discusses multiplication which may have different promoting rules than left shifting. My understanding is

I thought those terms where synonymous, but a note in MISRA regarding dead code indicates this to be wrong? What's the difference? Is one a subset of the other? Dead code - code that is executed but redundant, either the results were never used or adds nothing to the rest of the program. Wastes CPU performance. function(){ // dead code since it's calculated but not saved or used anywhere a + b; } Unreachable code - code that will never be reached regardless of logic flow. Difference is it's not executed. function(){ return x; // unreachable since returned a = b + c; } Dead Code Code that

The following code fails on a MISRA check. The concrete error message is: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } Why is the logical expression converted? What is converted here? Why does the code pass the MISRA check, when I swap One and MyVariable

MISRA C 2012 directive 4.12 is "Dynamic memory allocation should not be used". As an example, the document provides this sample of code: char *p = (char *) malloc(10); char *q; free(p); q = p; /* Undefined behaviour - value of p is indeterminate */ And the document states that: Although the value stored in the pointer is unchanged following the call to free, it is possible, on some targets, that the memory to which it points no longer exists and the act of copying that pointer could cause a memory exception . I'm ok with almost all the sentence but the end. As p and q are both allocated on the