<![CDATA[MISRA Discussion Forums - 6.16 Preprocessing directives (C++)]]>

<![CDATA[MISRA Discussion Forums - 6.16 Preprocessing directives (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 20:03:07 +0000 MyBB <![CDATA[Initialisation of multiple constant arrays WITHOUT #define]]> https://forum.misra.org.uk/showthread.php?tid=1577 Thu, 22 Jul 2021 14:22:58 +0000 misra cpp]]> https://forum.misra.org.uk/showthread.php?tid=1577 jonesthechip, but was lost when the bulletin board was migrated to MISRA's new website. It's been resubmitted by misra cpp

Unread post by jonesthechip » Wed May 26, 2021 10:27 am

A code base derived from an earlier C product has a large number of #define XYZ = {{1,2,3}} statements in a header.
The string defined by XYZ is used to initialise part of a ROM constant array, as follows:-

SpecialType ABC = {XYZ, 0, 1, pointer};

'SpecialType' is a structure with a three byte array that gets loaded with the replacement data from XYZ, and other sundry components.

This gets expanded to SpecialType ABC = {{{1,2,3}}, 0, 1, pointer};

The header file groups a number of replacements strings defined as XYZ, PQR, UTC, etc to keep the data (access parameters for comms) in one 'logical' place. Some replacement strings are used once, some in several other files to initialise other structures.

To achieve MISRA compliance means getting rid of all of these *&!^%$ macros. (Or more deviations than you can shake a stick at... Not ideal!)

However, it appears to be a classic case of "you don't really want to start from here"...

The optimum fix would be to re-write the code to use a pointer to a fixed string and bin the macros, putting all of the three byte arrays into a set of constant structures and sharing pointers to individual elements. This would lead to an unholy amount of retesting (and possibly my head on a stake, to deter others).

The least worst practical approach appears to be to bin the macros and edit the text replacement directly into all of the files, which although time-consuming does generate identical output binary files and therefore requires no re-testing. However, this does break the link between copies of the same data sets, so that a change to a particular set would require a search and edit through the code base.

So, today's question is: any better suggestions, please?

Regard

Sid Jones

You are right, this is currently non-compliant

See MISRA compliance 2020 for how this sort of issue can be managed.

The rule 16-2-2 is currently under review for the next issue]]> jonesthechip, but was lost when the bulletin board was migrated to MISRA's new website. It's been resubmitted by misra cpp

Unread post by jonesthechip » Wed May 26, 2021 10:27 am

A code base derived from an earlier C product has a large number of #define XYZ = {{1,2,3}} statements in a header.
The string defined by XYZ is used to initialise part of a ROM constant array, as follows:-

SpecialType ABC = {XYZ, 0, 1, pointer};

'SpecialType' is a structure with a three byte array that gets loaded with the replacement data from XYZ, and other sundry components.

This gets expanded to SpecialType ABC = {{{1,2,3}}, 0, 1, pointer};

The header file groups a number of replacements strings defined as XYZ, PQR, UTC, etc to keep the data (access parameters for comms) in one 'logical' place. Some replacement strings are used once, some in several other files to initialise other structures.

To achieve MISRA compliance means getting rid of all of these *&!^%$ macros. (Or more deviations than you can shake a stick at... Not ideal!)

However, it appears to be a classic case of "you don't really want to start from here"...

The optimum fix would be to re-write the code to use a pointer to a fixed string and bin the macros, putting all of the three byte arrays into a set of constant structures and sharing pointers to individual elements. This would lead to an unholy amount of retesting (and possibly my head on a stake, to deter others).

The least worst practical approach appears to be to bin the macros and edit the text replacement directly into all of the files, which although time-consuming does generate identical output binary files and therefore requires no re-testing. However, this does break the link between copies of the same data sets, so that a change to a particular set would require a search and edit through the code base.

So, today's question is: any better suggestions, please?

Regard

Sid Jones

You are right, this is currently non-compliant

See MISRA compliance 2020 for how this sort of issue can be managed.

The rule 16-2-2 is currently under review for the next issue]]> <![CDATA[Rules 16-2-3]]> https://forum.misra.org.uk/showthread.php?tid=1466 Tue, 05 Feb 2019 03:52:18 +0000 nishiyama]]> https://forum.misra.org.uk/showthread.php?tid=1466
If this multiple inclusion leads to multiple or conflicting definitions,
then this can result in undefined or erroneous behaviour.

I understood that it would be a multiple definition.

However, I do not understand the case of conflicting definition.
What kind of cases are there?]]>
If this multiple inclusion leads to multiple or conflicting definitions,
then this can result in undefined or erroneous behaviour.

I understood that it would be a multiple definition.

However, I do not understand the case of conflicting definition.
What kind of cases are there?]]> <![CDATA[Rules 16-2-1 and 16-2-2]]> https://forum.misra.org.uk/showthread.php?tid=1239 Thu, 28 Apr 2016 09:28:37 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1239
strictly interpreted, these rules ban conditional compilation, rendering rules 16-1-1 and 16-1-2 mute.
E.g.:

Code:
#ifdef FEATURE_X

// some code

#endif

Code:
#ifdef FEATURE_X

// some code

#endif

In addition, there appears to be no such rule in MISRA C 2012 (presumably, because it is a widely used feature in embedded systems):

Rule Mapping to MISRA C 2012
16-0-2 [Required] n.a. but namespaces are not available in C
16-1-1 [Required] n.a.
16-2-1 [Required] n.a.prohibits conditional compilation which is allowed in C
16-2-2 [Required] n.a.prohibits conditional compilation which is allowed in C

I would expect that a feature like the preprocessor, which is equal in C and C++, is treated equally across all MISRA standards.
Is there any chance this will be corrected/clarified in a new version or technical corrigendum?]]> <![CDATA[Rule 16-0-1 and extern "C"]]> https://forum.misra.org.uk/showthread.php?tid=1222 Thu, 14 Jan 2016 08:45:20 +0000 detra]]> https://forum.misra.org.uk/showthread.php?tid=1222 if we want to use the same Header files for "C" and "C++" we must use the "extern C" constuct. But the "extern C" construct must be placed before the include of the Header and so our tool reports a MISRA 16-0-1 violation. Is this violation valid? And if so, is there an other solution?

Code:
#ifndef _MYHEADER_

#define _MYHEADER_

extern "C"

{

    #include "firstheader.h"                // MISRA 16-0-1 violation

}

Thank you for help,
Stefan]]> if we want to use the same Header files for "C" and "C++" we must use the "extern C" constuct. But the "extern C" construct must be placed before the include of the Header and so our tool reports a MISRA 16-0-1 violation. Is this violation valid? And if so, is there an other solution?

Code:
#ifndef _MYHEADER_

#define _MYHEADER_

extern "C"

{

    #include "firstheader.h"                // MISRA 16-0-1 violation

}

Thank you for help,
Stefan]]>