+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C++ (https://forum.misra.org.uk/forumdisplay.php?fid=18)
+--- Forum: MISRA C++:2008 rules (https://forum.misra.org.uk/forumdisplay.php?fid=19)
+---- Forum: 6.16 Preprocessing directives (C++) (https://forum.misra.org.uk/forumdisplay.php?fid=144)
+---- Thread: Initialisation of multiple constant arrays WITHOUT #define (/showthread.php?tid=1577)
Initialisation of multiple constant arrays WITHOUT #define - misra cpp - 22-07-2021
Note this post was made by 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