misra

问题 MISRA enforces the use of the U suffix for unsigned integer constants uint32_t the_answer = 0x42U; I feel the U is a bit boilerplate because the line is very understandable without it. So I am wondering how much this rule is important and if unsigned int x = 1 is truely a bad example of implicit integer promotion. 回答1: You are correct, the U in this specific example is superfluous as per an exception to Rule 10.3: "A non-negative integer constant expression of essentially signed type may be

问题 I have a requirement to make a large amount of code MISRA compliant. First question: Can somebody to give an estimation for passing well written code for embedded system based on experience. I understand that "well written" is poorly defined and vague so i ask for raw estimation. Second question: Any recommendation for tool that can be customizable (i.e allowing suppress specific warnings) and used in automatic build environment (i.e command line interface) Any other useful suggestions that

问题 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

问题 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

问题 I am validating MISRA C:2012 standard to my MCU code using PC-Lint. I got following errors.Here I posted a sample code where I got errors on condition statements. 1] unsigned integer literal without a 'U' suffix [MISRA 2012 Rule 7.2, required] S_LCB_100, 2] side effects on right hand of logical operator, '&&' [MISRA 2012 Rule 13.5, required] while(( 0x00000000 != List[Loop] ) && ( 0 != Counter )) 3] : a signed value and an unsigned value cannot be used together as operands to != [MISRA 2012

问题 Why do the MISRA rules prohibit the use of #undef in a program? If I want to limit the scope of any macro, how to do it without using #undef ? 回答1: Basically, because MISRA is too paranoid and doesn't trust programmers to know what they are doing :-) Seriously, MISRA tries to prevent certain errors and is guided by the belief that if you forbid potentially problematic code constructs, reliability of software suddenly increases. Whether that is true is a matter of debate. In the case of #undef

问题 I have the following: typedef struct { uint8_t BlockID; uint32_t Copies; uint16_t Size; }NVMM_ConfigType; const NVMM_ConfigType NvmmCnf_Layout[6] = { { 1, 1, 4}, { 2, 3, 4}, { 5, 5, 16}, { 10, 1, 4}, { 11, 2, 32}, { 13, 1, 100}, }; Which seems fine to me, but, MISRA-C is giving the following error: MISRA C:2012 rule 10.3 violation: [R] The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category I've tried to figure out

问题 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)

问题 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

问题 I am currently working on a project which requires the code to be Misra 2012 compliant. Throughout the project we have lots of required misra warnings telling us we cant convert pointer to one type to a pointer to another type. Things as simple as void *memcpy(void *to, const void *from, size_t n) produce two Misra Required warnings since both to and from need to be type-casted to void* and const void* respectively. Conversion from void* to a pointer to any other type also gives a Misra