MISRA Discussion Forums
Portal

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

Username
  

Password
  

  Rule 3-4-1 and lifetimes, initialization, and side effects
Posted by: aromauld - 12-02-2025, 07:06 PM - Forum: 6.3 Basic concepts (C++) - Replies (1)

We have some interesting cases for Rule 3-4-1 which we aren't sure whether they are violations or not. Strictly adhering to the rule of reduced visibility could cause issues regarding lifetimes, initialization, and side effects of a constructor/destructor.

For instance, in the following example, is the intent to require changes to the code so that 'old_value' is not visible after the if body, or is `old_value` considered non-violating?

Code:
void fn(int a) {
    int old_value = a;
    a += 4;
    if (a > 10) {
        a = old_value;
    }
    // ...
}

Similarly, in cases where an object's constructor or destructor contains side effects, such as with a mutex, is the current visibility of 'merge_thread_lock' intended to be a violation?

Code:
void fn(int a) {
    std::unique_lock<std::shared_mutex> merge_thread_lock(global_mutex);
    if (global) {
      global = a;
      merge_thread_lock.unlock();
    }
    // ...
}
Print this item

  A8-4-5: Should have an exception for move constructors
Posted by: cgpzs - 05-02-2025, 09:45 AM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Our static analyzer is complaining about our move constructor because we are not moving the entire "oth" input. Instead, we are doing member-wise move, in compliance with A12-8-1:

Code:
class B
{
public:
  B(B&& oth) : ptr(std::move(oth.ptr)) // Compliant
  {
     oth.ptr = nullptr;
  }
};

Do you agree that A8-4-5 should explicitly clarify that the rule does not apply to move constructors?

Print this item

  A7-2-1 Still relevant in C++14?
Posted by: cgpzs - 29-01-2025, 10:03 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Rule A7-2-1 seems copied verbatim from the MISRA C++ 2008 rules. However, there's a key difference: C++14 has scoped enums. There, it is not unspecified (nor undefined) to cast an integer to the enum type when it is not any of the enumerators, since the valid range for the enum is the range of the underlying type. 

Based on that, what would be the rationale for keeping A7-2-1 in the AUTOSAR C++14 rules?

Print this item

  MISRA AC INT:2025
Posted by: misra-ac - 22-01-2025, 03:37 PM - Forum: MISRA AC resources - No Replies

This document explains the structure of, and relationships between, the MISRA Autocode Guidelines (MISRA AC) family of documents. It is based on the original version, 1.0, published in 2007. The document has undergone extensive revision to reflect the changes in the MISRA AC document family and related standards, and the advances in use and awareness of modelling and automatic code generation approaches since that time.



Attached Files
.pdf   MISRA AC INT V2.pdf (Size: 173.88 KB / Downloads: 2)
Print this item

  MISRA AC SLSF:2023 AMD3
Posted by: misra-ac - 13-01-2025, 10:58 AM - Forum: MISRA AC SLSF discussions - No Replies

This Amendment to MISRA AC SLSF:2023 contains modifications that bring the guidelines up to date for MATLAB release R2024b. It also includes revisions to the required statuses of some diagnostics and to the statuses of some library blocks and configurations.



Attached Files
.pdf   MISRA AC SLSF 2023 AMD 3.pdf (Size: 564.32 KB / Downloads: 2)
Print this item

  MISRA AC SLSF:2023 AMD3
Posted by: misra-ac - 13-01-2025, 10:57 AM - Forum: MISRA AC resources - No Replies

This Amendment to MISRA AC SLSF:2023 contains modifications that bring the guidelines up to date for MATLAB release R2024b. It also includes revisions to the required statuses of some diagnostics and to the statuses of some library blocks and configurations.



Attached Files
.pdf   MISRA AC SLSF 2023 AMD 3.pdf (Size: 564.32 KB / Downloads: 1)
Print this item

  Rule 7.0.6 - why the requirement of "id-expression"?
Posted by: cgpzs - 09-01-2025, 08:43 AM - Forum: 4.7 Standard conversions - Replies (1)

Rule 7.0.6 provides the following amplification for assigning numerical types:

2. The source and target shall have types of the same type category, signedness, the source size
shall be smaller than the target size, and the source shall be an id-expression;

Question: why must the source be an "id-expression"?

Consider this example:

Code:
struct Foo
{
  float bar;
};

float a;
Foo f;

double d1 = a;      // Compliant, since it's an id-expression
double d2 = f.bar;  // Non-compliant, since it's NOT an id-expression (it's a member-expression)

This is inconsistent. The fact that we are using a member-expression instead of an id-expression does not have any impact on how the conversion is made, it's equally safe. 

Would it make sense to remove the "id-expression" part of the rule? Otherwise, can you elaborate on why is it needed, what problems does it guard against?

Thanks!

Print this item

  rule 7.0.5: clarification regarding scope / expressions vs full expressions
Posted by: sks - 06-01-2025, 11:56 AM - Forum: 4.7 Standard conversions - Replies (1)

Hi,

as I understand it right now, rule 7.0.5 is very strict and often prevents unsigned integer types smaller than int from being used in a MISRA-compliant way. For example, take

Code:
const uint8_t cu8a = 0;
const uint16_t cu16a = 0;
static_assert(cu8a == cu16a);

Here, integral promotions happen on both the lhs and rhs of the == operator. Both are implicitly converted to int, thus changing from unsigned to signed, causing a violation to MisraC++ 2023 Rule 7.0.5.

But does Rule 7.0.5 even apply in this case? The rule is supposed to apply to "all expressions (including sub-expressions) of _numeric_ type". "cu8a == cu16a" is of type bool, so the rule does not apply to the full expression. However, the expressions on the LHS and RHS individually are of a numerical type and consist of the implicit "(int)cu8a" / "(int)cu16a.

The rule also states "For the usual arithmetic conversions, only the final type of an operand is considered." Which could suggest a restriction for operators that return integral types (otherwise the expression itself would not be of integral type and not considered at all).

The same case could be made with an implicit cast to bool, eg taking the sum or difference of cu8a and cu16a.

How exactly is the rule supposed to be scoped and what expressions / operands does it consider?

Print this item

  Rule 7.0.2: Unclear/questionable rationale
Posted by: cgpzs - 06-12-2024, 09:29 AM - Forum: 4.7 Standard conversions - Replies (1)

Hi,

Rule 7.0.2 bans any type of conversion to bool (implicit or explicit) anywhere in the code (with some exceptions). The rationale says:

"However, this interpretation may not be appropriate for APIs, such as POSIX, that do not use Boolean return values."

This sounds strange, why should modern C++17 code (that may not use C-style POSIX functions at all) be limited by this?

Could you show an example code that highlights how this is a problem and leads to unexpected behavior? For example, how is this code unsafe/can lead to unexpected results?

Code:
bool b1 = static_cast< bool >( 4 );  // Non-compliant

Conversion from fundamental types to bool is well-defined behavior as per [conv.bool]:

"A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true."

Thanks!

Print this item

  Rule 7.0.4 - exception for binary bitwise operators and constant operands?
Posted by: cgpzs - 05-12-2024, 01:06 PM - Forum: 4.7 Standard conversions - Replies (4)

Hi,

My interpretation of Rule 7.0.4 is that it does not allow this type of code:

Code:
my_function(FLAG_A | FLAG_B | FLAG_C);

This is quite frequent when interfacing with third-party as well as POSIX C APIs. Casting each argument to unsigned type would go in detriment of readability.

Would it make sense to add an exception for signed constants?

Thanks!

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,194
» Latest member: first4landlord1advice
» Forum threads: 1,008
» Forum posts: 2,779

Full Statistics

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

Latest Threads
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
17-02-2025, 02:14 PM
» Replies: 2
» Views: 145
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
14-02-2025, 01:04 PM
» Replies: 3
» Views: 1,218
Rule 3-4-1 and lifetimes,...
Forum: 6.3 Basic concepts (C++)
Last Post: misra cpp
14-02-2025, 01:02 PM
» Replies: 1
» Views: 119
Application of Rule 15.0....
Forum: 4.15 Special member functions
Last Post: misra cpp
07-02-2025, 12:44 PM
» Replies: 3
» Views: 2,607
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: misra cpp
07-02-2025, 12:43 PM
» Replies: 3
» Views: 751
A7-2-1 Still relevant in ...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
31-01-2025, 01:20 PM
» Replies: 1
» Views: 220
MISRA AC INT:2025
Forum: MISRA AC resources
Last Post: misra-ac
22-01-2025, 03:37 PM
» Replies: 0
» Views: 155
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
13-01-2025, 10:58 AM
» Replies: 0
» Views: 205
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC resources
Last Post: misra-ac
13-01-2025, 10:57 AM
» Replies: 0
» Views: 198
Rule 7.0.4 - exception fo...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:26 PM
» Replies: 4
» Views: 856