22-02-2019, 07:44 PM
Good day. I'm analyzing a few findings reported by a static analysis tool for a project that per project guidelines disallows any use of standard libraries. This maximizes control over the code and makes all the project code subject to MISRA C compliance. To comply with MISRA C:2012 and to avoid possible clashes with unit testing frameworks that do make use of standard libraries the internal standard-like macros and functions (like "offsetof" and "memcpy") have customized names.
Problems arise when trying to adhere to the rule 11.9 by defining the macro "NULL" and to the directive 4.6 by defining the exact-width integer types. These rules prescribe the use of standard names while the rules 21.1 and 21.2 prohibit such definitions. The project employs static assertions to guarantee that all the standard properties of the exact-width integer types and other integer types (like "size_t" and "ptrdiff_t") hold true for whatever (32-bit or 64-bit) target the project is compiled. The project is C99-specific, and I assume the MISRA C Working Group would rightfully point out that the directive 4.6 recommends inclusion of "stdint.h" in this case and therefore does not strictly contradict the rule 21.2 due to the standard headers being out of the MISRA C compliance scope. In any case the rationale of the rule 21.2 does not seem to apply here, as the typedef-names have no linkage and are therefore not reserved as per "C99. 7.1.3 Reserved identifiers" as long as no associated header is included.
My questions are:
1) How can the contradiction between the rules 11.9 and 21.1 be resolved with respect to the macro "NULL" in the context of the given project?
2) How can the contradiction between the directive 4.6 and the rule 21.2 be resolved with respect to the exact-width integer types in the context of the given project?
3) Rule 21.1 acknowledges that defining identifiers being subject to the question 2 "is well-defined provided that the header is not included", but still prohibits such definitions to avoid confusion. Does this prohibition also apply for the rule 21.2? What exactly causes confusion provided all the properties guaranteed by the standard are also ensured for the definitions made outside of the standard headers?
Kind regards
Problems arise when trying to adhere to the rule 11.9 by defining the macro "NULL" and to the directive 4.6 by defining the exact-width integer types. These rules prescribe the use of standard names while the rules 21.1 and 21.2 prohibit such definitions. The project employs static assertions to guarantee that all the standard properties of the exact-width integer types and other integer types (like "size_t" and "ptrdiff_t") hold true for whatever (32-bit or 64-bit) target the project is compiled. The project is C99-specific, and I assume the MISRA C Working Group would rightfully point out that the directive 4.6 recommends inclusion of "stdint.h" in this case and therefore does not strictly contradict the rule 21.2 due to the standard headers being out of the MISRA C compliance scope. In any case the rationale of the rule 21.2 does not seem to apply here, as the typedef-names have no linkage and are therefore not reserved as per "C99. 7.1.3 Reserved identifiers" as long as no associated header is included.
My questions are:
1) How can the contradiction between the rules 11.9 and 21.1 be resolved with respect to the macro "NULL" in the context of the given project?
2) How can the contradiction between the directive 4.6 and the rule 21.2 be resolved with respect to the exact-width integer types in the context of the given project?
3) Rule 21.1 acknowledges that defining identifiers being subject to the question 2 "is well-defined provided that the header is not included", but still prohibits such definitions to avoid confusion. Does this prohibition also apply for the rule 21.2? What exactly causes confusion provided all the properties guaranteed by the standard are also ensured for the definitions made outside of the standard headers?
Kind regards
<t></t>