misra

I'm having some trouble with a pointer declaration that one of my co-workers wants to use because of Misra C requirements. Misra (Safety Critical guideline) won't let us mere Programmers use pointers, but will let us operate on arrays bytes. He intends to procur a pointer to an array of bytes (so we don't pass the actual array on the stack.) // This is how I would normally do it // void Foo(uint8_t* pu8Buffer, uint16_t u16Len) { } // This is how he has done it // void Foo(uint8_t (*pu8Buffer)[], uint16_t u16Len) { } The calling function looks something like; void Bar(void) { uint8_t u8Payload

My static analyzer is throwing the following warning: MCPP Rule 5-0-3: This complex expression is implicitly converted to a different essential type for the following code: void func(const uint32_t arg) { //32U has underlying type uint8_t const uint32_t u32a = arg % 32U; //warning issued in this line const uint32_t u32b = (arg % static_cast<uint32_t>(32U)); //same warning issued in this line const uint32_t u32c = static_cast<uint32_t>(arg % 32U); //compliant } According to MISRA underlying type conversion rules: Otherwise, if both operands have integral type, the underlying type of the

Our company are now ISO-13485 (Medical devices) and wants to use MISRAC2012. I read the standard, but I cannot figure out whether or not I am allowed to disable some rules if I think it could improve both stability and readability. Two examples: MISRA only allows 1 return statement per function. This often lead to nested conditional structures that look like Christmas tree. I really don't think this rule increase safeness because it makes the code less readable and more error prone. MISRA only accept functions that have a prototype, even for static ones. This allows the programmer to place his

MISRA 14.5 says continue statement must not be used. Can anyone explain the reason? Thank you. It is because of the ancient debate about goto , unconditional branching and spaghetti code, that has been going on for 40 years or so. goto , continue , break and multiple return statements are all considered more or less equally bad. The consensus of the world's programming community has roughly ended up something like: we recognize that you can use these features of the language without writing spaghetti code if you know what you are doing. But we still discourage them because there is a large

I switched to fixed-length integer types in my projects mainly because they help me think about integer sizes more clearly when using them. Including them via #include <inttypes.h> also includes a bunch of other macros like the printing macros PRIu32 , PRIu64 ,... To assign a constant value to a fixed length variable I can use macros like UINT32_C() and INT32_C() . I started using them whenever I assigned a constant value. This leads to code similar to this: uint64_t i; for (i = UINT64_C(0); i < UINT64_C(10); i++) { ... } Now I saw several examples which did not care about that. One is the

I need someone who has more experience with MISRA to help me to solve this. I have the following code: byte* buf = new(std::nothrow) byte[bufferSize]; ..... for (uint32_t i = 0; i < bufferSize; i+=4) { .............. { buf[ i+0 ] = b; buf[ i+1 ] = g; buf[ i+2 ] = r; (1) Event misra_violation: [Required] MISRA C++-2008 Rule 5-0-15 violation: Array indexing shall be the only form of pointer arithmetic. buf[ i+3 ] = a; } MISRA Rule 5-0-15 doesn't allow also ptr++ or ptr--. What should be the approach here to increment/decrement and assign values using pointers created by new? My MISRA checker is