Advertisement

ChrisTapp

image

Biography has not been added

ChrisTapp

's contributions
Articles
Comments
    • I am another one who needs to declare an interest. I am the current Chairman of the MISRA C++ Working Group and a member of the MISRA C Working Group, but I am posting here in a personal capacity. Some more points about MISRA: 1) Having "MISRA Compliant" code does not, by itself, mean you have good quality code. 2) Having code that it not "MISRA Compliant" does not mean you have bad quality code. 3) MISRA compliance is not absolute - it will depend on the tool(s) and process(es) used to check for compliance, especially when checking for compliance with undecidable rules. I have seen high-quality code that is not MISRA compliant and low-quality code that is. More importantly, code that is of high-quality that was not written to be MISRA compliant is likely to contain many MISRA violations; I would only be concerned if some of these violations are traceable to undefined or unspecified behaviour within the C language. Many of the MISRA rules basically say "if you write your code like this, you will ensure that defects related to X will not be present" - there are other, equally valid, ways of ensuring these objectives are met. It is also worth thinking about the number of violations. For example, the register definition header files for processors often cast integer constants (addresses) to pointers to a specific type to allow registers to be accessed, with each of these containing multiple MISRA violations (you shouldn't do this stuff in code, but it is perfectly sensible for the compiler implementation to do it to provide access to the hardware). If this header file contained 1000 MISRA violations and was included in 10 files within a project, would that mean there are 10 000 "dangerous code constructs" to worry about?