Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





  Initialisation of multiple constant arrays WITHOUT #define
Posted by: misra cpp - 22-07-2021, 02:22 PM - Forum: 6.16 Preprocessing directives (C++) - No Replies

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

Print this item

  New forum release notes
Posted by: david ward - 20-07-2021, 03:36 PM - Forum: Announcements - No Replies

Hello everyone, just a few notes concerning the new forum. Due to database migration issues please note the following:

  • If you registered after 21 May 2021 for the old forum you will need to register again.
  • If you registered before this date your account has been ported across but you will need to reset your password, please see the link at the top of this page.
  • We are working on reinstating posts made after 21 May – these will be reposted by one of the official MISRA accounts with the headline "Originally posted by nnn".
  • Downloads in the "Resources" section have now been reinstated.
If you find any other issues please get in touch via the "Contact us" form.

Print this item

  Comments are needed for Rule 6-4-2? and should be placed inside the "else" block?
Posted by: chenzhuowansui - 02-04-2021, 03:02 AM - Forum: 6.6 Statements (C++) - Replies (2)

Hi,

With regards to Rule 6-4-2

Quote:All if … else if constructs shall be terminated with an
else clause.
we have some different interpretations, so could you kindly help clarify the following questions for us:
1. The rule only talks about "if … else if constructs shall be terminated with an else clause." in the title, and doesn't mention anything about adding necessary comments for the else clause in the title. However, in the rationale part, it indeed mentions that the final else statement should "either take appropriate action or contain a suitable comment", the question is: shall we take the rationale part into account to interpret this rule, more specifically, is the following code snippet compliant?
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else
{
}

2. If the comments are necessary, where shall it be placed: right in the else block? or any places around the else clause, for example, are the following cases compliant?
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
// No change in value of x
else
{
}
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else // No change in value of x
{
}
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else
// No change in value of x
{
}
Many thanks in advance!

Print this item

  Rule 11-0-1 and POD types
Posted by: cgpzs - 24-03-2021, 01:57 PM - Forum: 6.11 Member access control (C++) - Replies (1)

Hi,

I have a few questions about rule M11-0-1:

Rule 11–0–1
(Required)
Member data in non-POD class types shall be private.

* As posted in a previous question, "class types" here means "class, struct or union". Is my understanding correct?
* Why should the fact that a type is POD or not influence access control?

Let's have the following controversial example. Having the following POD type:

Code:
struct Foo
{  
   int x;
   int y;
};

The design for this struct is to aggregate 2 variables together, but there's no invariance to hold. x and y can vary independently. The struct is POD, so it's compliant with M11-0-1.

Now, in the future we want to extend `Foo` with another variable independent from x and y:

Code:
struct Foo
{
    int x;
    int y;
    std::string name;
};

Now, since `Foo` contains a `std::string`, and `std::string` is not a POD, then `Foo` becomes a non-POD. In turn, this now violates M11-0-1, which forces us to make these fields private. This leads to adding trivial boilerplate getters and setters to `Foo`, and every consumer of this struct needs to change their way of interacting with `Foo`.

This wouldn't happen if `name` was a `char const*`:

Code:
struct Foo
{
    int x;
    int y;
    char const* name;
};

The semantics of `Foo` are identical to before, just using a different type for one of its members. Why should that lead to such dramatic changes?

A similar example:

Code:
struct Bar
{
    std::vector points_x;
    std::vector points_y;
};

`Bar` is a collection of points that are independent from each other; there's no invariant.

Besides, POD types are types that are "compatible with the types used in the C programming language". Why should this be a concern if we are programming in C++? Why should we make our structs "C-compatible", if they are meant to be used in C++ code?

Print this item

  choosing C compiler
Posted by: scb1993 - 04-03-2021, 02:11 AM - Forum: General Questions - No Replies

Hello Sir,

I was going through MISRA C 2012 rules, Does MISRA says any guidelines to choose compiler for C as there are many compilers available in the market.

Regards
Subhra

Print this item

  MISRA C:2012 permits published
Posted by: david ward - 01-03-2021, 02:28 PM - Forum: Announcements - No Replies

The MISRA C:2012 Permits are now available as a free download from the "Resources" section of this Bulletin Board.

The MISRA C:2012 Permits presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2012 guidelines. It should be used in conjunction with MISRA Compliance:2020, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

Print this item

  MISRA C:2012 permits
Posted by: david ward - 01-03-2021, 01:22 PM - Forum: MISRA resources - No Replies

No sooner had the MISRA C:2004 Permits been published, the question was asked “When will MISRA C:2012 Permits be published?” The wait is now over ...

MISRA C:2012 Permits provides a set of permits to aid compliance, particularly in the lower-levels (e.g. hardware access), but also to make compliance easier where automatically generated code is being created.

A related Guideline Reclassification Plan for Automatically Generated Code is being worked on, and will be released in due course.

This document presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2012 guidelines. It should be used in conjunction with MISRA Compliance:2020, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

The number of deviation permits within this document is expected to grow and it is possible that existing deviation permits may be revised. The document contains a table with a record of these changes.

The current release is Edition 1, published March 2021.



Attached Files
.pdf   MISRA C 2012 Permits (First Edition).pdf (Size: 812.01 KB / Downloads: 0)
Print this item

  6-5-4: on variable or expression?
Posted by: Nadege - 29-01-2021, 11:06 AM - Forum: 6.6 Statements (C++) - Replies (1)

Hello,

6-5-4 says "The loop-counter shall be modified by one of: --, ++, - = n, or + = n; where n remains constant for the duration of the loop"

Should this code below raise 6-5-4?

int main() {
int k = 8;

for (int j = 0; j < 10; j += k + 3) {
}
}

If 'n' concerns variable only, I would say 'Yes'.
If 'n' concerns expressions, I would say 'No'.

What do you think?
Thanks in advance for your help.

Nadège

Print this item

  MISRA AC guidelines public review Jan 21
Posted by: david ward - 22-01-2021, 04:34 PM - Forum: MISRA AC GMG discussions - No Replies

MISRA is pleased to announce that drafts of new versions of its Autocode documents MISRA AC GMG "Generic Modelling Design and Style Guidelines" and MISRA AC SLSF "Modelling Design and Style Guidelines for the Application of Simulink and Stateflow" will shortly be available for public review.

The revision process has focused on the following:

  • Addressing feedback raised on the previous versions
  • Seeking to reduce areas of ambiguity and inconsistency
  • Updating SLSF for more recent revisions of the MathWorks toolset with expanded capabilities and, in some areas, modelling semantics
  • Further clarifying and extending Stateflow usage guidelines to define more tightly a standardized usage style from a subset of Stateflow’s capabilities

If you would like to be considered as a reviewer please download the attached file and return it to us via email. We will review applications and be in touch with next steps in due course. Please note that in the case of high levels of interest we may not be able to accept all offers of reviews.

Updated Feb 2021. The call for reviewers is now closed and we will be sending out the review package shortly. Thank you to everyone that has expressed interest

Print this item

  Rule 10.4 and essentially signed integer constant expressions
Posted by: jaska - 19-01-2021, 02:34 PM - Forum: 8.10 The essential type model - No Replies

Rule 10.3 exception 1 allows assigning a signed integer constant expression to an essentially unsigned type, if the value can be represented in that type; u8 = 2 * 24; is allowed.
Rule 10.4 has no such exception
Expressions like u32 > 0, u8 != 0, and u32 += 1 violate rule 10.4.

Now:

uint32_t u32idem(uint32_t x) { return x; }
bool less_u32(uint32_t a, uint32_b ) { return a < b; }

if (u32 < u32idem(1)) { /* accepted by 10.3 and 10.4 */
} else if (less_u32(u32, 3)) { /* accepted by 10.3 (and 10.4) */
} else if (u32 < 4u) { /* fine by 10.4 */
} else if (u32 < 7) { /* violates 10.4 */
} else if (11u > u32) { /* ok, remove u and it's not */
} else {
switch (u32) {
case 23: /* ok */
...

Why are binary operators handled differently from assignments and switch cases? I think the exception should be the same for both 10.3 and 10.4 ?

Why is there no exception for Rule 10.4 allowing an integer constant expression to be used in a binary expression?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 5,589
» Latest member: mesutsert001
» Forum threads: 866
» Forum posts: 2,386

Full Statistics

Online Users
There are currently 79 online users.
» 0 Member(s) | 77 Guest(s)
Bing, Google

Latest Threads
Initialisation of multipl...
Forum: 6.16 Preprocessing directives (C++)
Last Post: misra cpp
22-07-2021, 02:22 PM
» Replies: 0
» Views: 16
Rule 0-1-6 and Boolean va...
Forum: 6.0 Language independent issues (C++)
Last Post: misra cpp
22-07-2021, 02:15 PM
» Replies: 13
» Views: 2,374
Rule 3-2-1 and compatible...
Forum: 6.3 Basic concepts (C++)
Last Post: misra cpp
22-07-2021, 02:11 PM
» Replies: 3
» Views: 1,423
Comments are needed for R...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
22-07-2021, 02:07 PM
» Replies: 2
» Views: 589
Rule 8–4–4 (Required)...
Forum: 6.8 Declarators (C++)
Last Post: misra cpp
22-07-2021, 02:00 PM
» Replies: 5
» Views: 7,742
New forum release notes
Forum: Announcements
Last Post: david ward
20-07-2021, 03:36 PM
» Replies: 0
» Views: 28
MISRA C:2012 Amendment 1
Forum: General Questions
Last Post: david ward
20-07-2021, 12:34 PM
» Replies: 7
» Views: 11,439
Rule 11-0-1 and POD types
Forum: 6.11 Member access control (C++)
Last Post: misra cpp
20-07-2021, 11:34 AM
» Replies: 1
» Views: 330
choosing C compiler
Forum: General Questions
Last Post: scb1993
04-03-2021, 02:11 AM
» Replies: 0
» Views: 776
MISRA C:2012 permits publ...
Forum: Announcements
Last Post: david ward
01-03-2021, 02:28 PM
» Replies: 0
» Views: 821