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

Username
  

Password
  





  Rule 9.2 zero initialization of array of struct
Posted by: sowisojh - 27-04-2022, 11:28 AM - Forum: 6.9 Initialisation - Replies (1)

I Have the following code:

Code:
#include <stdint.h>

typedef struct {
    int16_t foo;
    int16_t bar;
} foobar_t;

static foobar_t foobars[42] = {0};

In rule 9.2 the following is given:

Quote:Note also that all the elements of arrays or structures can be initialised (to zero or NULL) by giving an
explicit initialiser for the first element only. If this method of initialisation is chosen then the first
element should be initialised to zero (or NULL), and nested braces need not be used.


Is the zero initialization of foobars compliant with Rule 9.2?

Lint is complaining about this kind of initialization, but I'm not sure if it is right or not
Warning: LINT [W940] omitted braces within an initializer [MISRA 2004 Rule 9.2]


The rule mentions that the first element should be initialized to zero. The first element, which can be listed in the initialization list, would be the member foo of the first struct of the first array element. Setting this to 0 would, in my understanding, comply with rule 9.2. As in the last sentence "... nested braces need not be used" is mentioned, no further braces around the 0 are required.

Print this item

  MISRA C:2012 TC2
Posted by: david ward - 20-04-2022, 06:40 PM - Forum: MISRA resources - No Replies

We are pleased to announce the publication of MISRA C:2012 Technical Corrigendum 2 (MISRA C:2012 TC2). This document provides additional clarification on MISRA C:2012 and should be read in conjunction with either

  • MISRA C:2012 (Third Edition, First Revision) Guidelines for the use of the C language in critical
    systems, as revised by
  • MISRA C:2012 Amendment 2, Updates for ISO/IEC 9899:2011 Core functionality
or
  • MISRA C:2012 (Third Edition) Guidelines for the use of the C language in critical systems, as
    revised by:
  • MISRA C:2012 Amendment 1, Additional security guidelines for MISRA C:2012
  • MISRA C:2012 Amendment 2, Updates for ISO/IEC 9899:2011 Core functionality
  • MISRA C:2012 Technical Corrigendum 1



Attached Files
.pdf   MISRA C 2012 TC2.pdf (Size: 166.76 KB / Downloads: 59)
Print this item

  M9-3-3 and observable state
Posted by: kth - 14-04-2022, 01:32 PM - Forum: AUTOSAR C++:2014 rules - Replies (3)

The AUTOSAR Guidelines for the use of the C++14 language in critical and safety-related systems (Release 19-03/latest) basically reuse MISRA C++ Rule 9-3-3 as M9-3-3 but add two clarification notes and a reference to C++ Core Guidelines 

  • Con.2: By default, make member functions const.

The rationale of Con.2 explicitly uses "observable state": 

Quote:Reason A member function should be marked const unless it changes the object’s observable state. This gives a more precise statement of design intent, better readability, more errors caught by the compiler, and sometimes more optimization opportunities.

Motivation of this post is that our static analysis tool currently reports a M9-3-3 finding for this code:
Code:
class B final {
public:
  B(int* dest) : p_{dest} {}
 
  int& Get() { return *p_; }  // M9-3-3 reported
 
  // Here adding const to Get() does not lead to a compiler error, due to the indirection that is introduced with
  // the pointer 'p_'. However, adding const without changing the return type to 'const int&' is missleading.
private:
  int val_{0};
  int* p_{&val_};
};



A similar example with shared_ptr:
Code:
class Data
{
  public:
    // changes the observable state
    void Set(int val) noexcept
    {
      val_ = val;
    }

    int Get() const noexcept
    {
      return val_;
    }

  private:
    int val_;
};

class WithSharedPtr {
  public:

    void SetValue() {  //< M9-3-3 Method can be declared const reported here
      sptr->Set(3);
    }

    void ChangePtr() {
      sptr = std::make_shared<Data>();
    }

    int GetValue() const {
      return sptr->Get();
    }

  private:
    std::shared_ptr<Data> sptr = std::make_shared<Data>();
};

For both findings adding const is technically possible, but the observable state is changed.

My question: what is the correct interpretation of MISRA C++ 9-3-3 and AUTOSAR M9-3-3?

Print this item

  3-2-4 and pure virtual functions
Posted by: Tobias Loose - 10-04-2022, 06:19 AM - Forum: 6.3 Basic concepts (C++) - Replies (1)

Hi!

Rule 3-2-4 states:


Quote:An identifier with external linkage shall have exactly one definition.


This would also apply to pure virtual functions of abstract base classes. I have personally never seen anyone use that feature and gather from reading up about it that it is questionable design to supply definitions for those. In most cases, these functions would be empty and collide with rules about unused code anyway.

Was this intended or an oversight? I propose to add an exception for pure virtual functions.

Also, I propose to replace "An" with "All". Otherwise, it would be enough to add one variable somewhere and provide a definition for it.

Thanks!

Print this item

  Conflict 12-1-3 and 12-1-2
Posted by: Tobias Loose - 08-04-2022, 02:13 PM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Hi!

The text of A12-1-2:


Quote:Both NSDMI and a non-static member initializer in a constructor shall not be used in the same type.


And A12-1-3:

Quote:If all user-defined constructors of a class initialize data members with constant values that are the same across all constructors, then data members shall be initialized using NSDMI instead.


These are in conflict if a type initializes some members to a constant cross all constructors, but other members to non-constant values. The conflict arises from having to move the constant member's initializer to NSDMI and having to do the same thing with the other members (for A12-1-2) but not being able to (due to their dependence on constructor arguments).

Initializing to one value and then overwriting in the ctor body with another value is not an option when the member is const or when there is no cheap first initialization (e.g. due to dynamically allocated memory etc.).

I suggest revising A12-1-3 to:

Quote:If all user-defined constructors of a class initialize all data members with constant values that are the same across all constructors, then data members shall be initialized using NSDMI instead.


Thanks!

Print this item

  A4-5-1 with ternary conditional operator
Posted by: Tobias Loose - 08-04-2022, 06:29 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Hi!

The rule states:


Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.


I can understand the rule insofar as to avoid confusion that is caused by using the underlying type arithmetically. However, this also excludes the ternary conditional operator, and thus, this IMHO perfectly fine code:

Code:
void foo()
{
   enum class Thing { One, TheOther };

   bool which_one = g();

   const Thing selected_thing = which_one ? Thing::One : Thing::TheOther; // Non-compliant with A4-5-1
}

Please note that turning this into an "if" will add another statement and preclude "selected_thing" from being const. Depending on the C++ version, this also precludes the surrounding function from being constexpr (because of the extra statement). In my opinion, the demonstrated usage should be allowed in general.

Is it an oversight to disallow enum values in these cases, or is there a specific reason? If there is a reason, I would urge you to overthink your stance on this w.r.t. the upcoming MISRA C++.

Edit: Also, this code violates A5-16-1, because it uses the ternary conditional operator as a subexpression of the assignment expression. I guess this is an oversight in A5-16-1, which should have an exception for assignment expressions.

Thanks!

Print this item

  5-2-10 with non-arithmetic operators
Posted by: Tobias Loose - 05-04-2022, 12:34 PM - Forum: 6.5 Expressions (C++) - Replies (1)

Hi!

The rule states 


Quote:The increment (++) and decrement (--) operators should not be mixed with other operators in an expression.


The code checker we employ also flags the usage of these operators in expressions that contain member-access operators, subscript operators, and the like.

The rationale and example appear to focus on other arithmetic operators, which makes sense.

Is this an oversight in the rule formulation (missing "arithmetic"), or is the following intentionally non-compliant with 5-2-10?

Code:
void foo()
{
    struct A { int b; };

    A a{0};

    a.b++; // Non-compliant

    int c[3] = {1, 2, 3};

    c[2]++; // Non-compliant

    A* const a_ptr = &a;

    a_ptr->b++; // Non-compliant
}

Thanks!

Print this item

  Rule 5-0-6 about underlying type of boolean bit field
Posted by: zhaohui - 01-04-2022, 09:08 AM - Forum: 6.5 Expressions (C++) - Replies (1)

Quote:Rule 5–0–6 (Required) An implicit integral or floating-point conversion shall not reduce the size of the underlying type.

Refer to the Bit-field operands part of determination of the underlying type of an expression
Quote:Bit-field objects have an underlying type equivalent to an integral type of a size determined by their width. For example, a bit-field with width n, will have the same underlying type as a fundamental type with the same sign and width (if one exists).

However, for one bit field, there's no any fundamental type with only one bit.
So what exactly are bitAs' and bitBs' underlying types? Please help to clarify, thanks.

Code:
struct
{
    bool bitA : 1;
    int  bitB : 1;
} boolbitfield;

int main()
{
    bool b = boolbitfield.bitA; // compliant or non-compliant?
}

Print this item

  A16-0-1 Use #define for conditional file inclusion?
Posted by: cgpzs - 25-03-2022, 01:57 PM - Forum: AUTOSAR C++:2014 rules - Replies (3)

Hi,

It's not clear if A16-0-1 allows using #define exclusively for creating header guards, or also for conditional file inclusion. Could you comment on that?

Example:

Code:
// foo.h
#if defined (SOMETHING) && !defined (SOMETHING_ELSE)  // Complex logic that we don't want to repeat everywhere
  #define SHOULD_INCLUDE_A              // Violating A16-0-1?
#else
  #define SHOULD_INCLUDE_B              // Violating A16-0-1?
#endif

// bar.h
#if   defined (SHOULD_INCLUDE_A)
  #include "bar_a.h"
#elif defined (SHOULD_INCLUDE_B)
  #include "bar_b.h"
#endif

// baz.h
#if   defined (SHOULD_INCLUDE_A)
  #include "baz_a.h"
#elif defined (SHOULD_INCLUDE_B)
  #include "baz_b.h"
#endif

Thanks!

Print this item

  Rule M7-3-4 and UDLs
Posted by: davebrown - 18-03-2022, 01:27 PM - Forum: AUTOSAR C++:2014 rules - Replies (3)

When using UDLs like the ones provided by std::chrono, for example, we get a violation of rule M7-3-4 when including the UDL namespace:

Code:
using namespace std::chrono_literals; // <- violation here

Naturally, this rule was written before UDLs were a thing and so it's inevitably not designed for this use case.

We have discussed two options for this:
  1. Partially deviate for this use case only
  2. Explicitly import the required UDL(s)
The first option is probably okay if we can limit the scope sufficiently but someone has to write it and defend it.
The second option requires writing code similar to:
Code:
using std::chrono_literals::operator""s;
using std::chrono_literals::operator""ms;
which is a little cumbersome, especially for developers unfamiliar with how a UDL is written.

What I would like to know is how MISRA intends to handle UDLs in the upcoming guidelines? If they are allowed, how should they be imported for convenient use? Will M7-3-4 be updated to include an exception for namespaces that define UDLs?

Thank you in advance for you time.

/Dave

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,205
» Latest member: domarant
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 164 online users.
» 0 Member(s) | 161 Guest(s)
Bing, Google, UptimeRobot

Latest Threads
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: cgpzs
17-04-2025, 12:10 PM
» Replies: 0
» Views: 156
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 281
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 269
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 179
Rule 8.2.8 - why aren't a...
Forum: 4.8 Expressions
Last Post: misra cpp
28-03-2025, 01:05 PM
» Replies: 1
» Views: 196
Typo in Appendix C of MIS...
Forum: 8.10 The essential type model
Last Post: Yordan Naydenov
17-03-2025, 02:58 PM
» Replies: 0
» Views: 155
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 232
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 199
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 258
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
21-02-2025, 12:58 PM
» Replies: 3
» Views: 672