Welcome to the MISRA discussion forum

I could not find the MISRA C ++ 2008 example suites.
There is only MISRA C related stuff in Resources.
Is there MISRA C ++ 2008 example suites deployment plan?

A revised version of MISRA C:2012 is now available in both hardcopy and PDF formats. This revised version consolidates the 2012 edition with Amendment 1 (Additional Security Guidelines) that was published in 2016, and the 2017 Technical Corrigendum 1.

The revised document is available now to purchase from the webstore, and PDF versions purchased from today (5 March 2019) will also deliver the new edition. If you previously purchased MISRA C, we regret that upgrades to single-user PDFs are not available, but the Technical Corrigendum and Amendment 1 are still available as a standalone document from the Resources section of this Bulletin Board. Tool vendors and corporate licensees who wish to upgrade should contact us for details.

Consider the following example:

The document MISRA:C Addendum 3 classifies the CERT C rule FIO34-C as NOT COVERED by MISRA (Coverage is None/None)

However, the condition detailed in this rule FIO34-C seems to be fully covered by MISRA rule 22.7

FIO34-C: Distinguish between characters read from a file and EOF or WEOF
MISRA C:2012 Amendment 1, Rule 22.7: The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF

Is that correct?

The following description is in section 10.2 of the C ++ language standard.

Quote:Name lookup can result in an ambiguity, in which case the program is ill-formed.

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

Hello,

We have some doubts about Rule 21.3 and Rule 21.8, please help clarify

Rule 21.3 The memory allocation and deallocation functions of shall not be used
Rule 21.8 The library functions abort, exit, getenv and system of shall not be used

From the titles and Rationale of these two rules, they are talking about only functions with the forbidden identifiers, but in the Amplification of these two rules, all these identifiers and macros are forbidden including using these identifiers to define variables or fields of structs. So my question is that can we use these identifiers in the following cases:

I have an issue regarding the rule violation in which I'm using a 2D array inside a structure and apparently The Rule 17.4 says it isn't compliant. Is Declaring arryas inside a structure/union not compliant and why is it so? What exactly is the alternative for it?
Help would be appreciated ASAP. Following is the example code. Thanks in advance.

For example:

Rule 2-10-2 is defined in terms of "block scopes" and "nested blocks". The only example is of a function and there is no mention of classes nor namespaces. Does "block" refer only to a compound statement as part of a function body, or is the intention to include other curly-brace-enclosed regions or scopes? For example, are any of the indicated lines violations of rule 2-10-2?