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

Username
  

Password
  





  Rule 8.7: clarifications of no linkage for an object
Posted by: chenzhuowansui - 28-04-2022, 06:18 AM - Forum: 8.8 Declarations and defnitions - Replies (1)

Hi there,

could anyone help explain the following sentence in the Rationale part of Rule 8.7



Quote:Restricting the visibility of an object by giving it internal linkage or no linkage reduces the chance that
it might be accessed inadvertently.


as specified by the C standard:



Quote:If the declaration of an identifier for a function has no storage-class specifier, its linkage
is determined exactly as if it were declared with the storage-class specifier extern. If
the declaration of an identifier for an object has file scope and no storage-class specifier,
its linkage is external.


if an object is declared with no linkage, the default linkage is external linkage, so why giving no linkage to an object could restrict the visibility and reduces the chance that it might be accessed inadvertently?

thanks!

Print this item

  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: 58)
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

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

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

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
22-11-2024, 10:11 AM
» Replies: 0
» Views: 23
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 35
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 369
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 324
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,441
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,860
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,498
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,690
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,246
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 430