MISRA Discussion Forums
Portal

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

Username
  

Password
  

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

  Rule 6.2.1: non-inline constexpr variables in headers?
Posted by: cgpzs - 22-11-2024, 10:11 AM - Forum: 4.6 Basic concepts - Replies (2)

Hi, 

Consider the following example:

Code:
// foo.h
constexpr int kFoo = 123;

inline int foo(int x)
{
  return x * kFoo;
}

// tu1.cpp
#include "foo.h"
int tu1() { return foo(1); }

// tu2.cpp
#include "foo.h"
int tu2() { return foo(2); }

Does the function "foo" violate Rule 6.2.1 in this context, given that kFoo is not a C++17 inline variable? 
Or would it violate 6.2.1 only if kFoo were ODR-used (for example, passed by reference)?

Thanks!

Print this item

  Rule 0.1.2
Posted by: stephanmuench - 21-11-2024, 01:12 PM - Forum: 4.0 Language independent issues - Replies (1)

Dear MISRA members,

I would have a question about MISRA C++:2023 Rule 0.1.2 which mentions in its rationale
"Overloaded operators are excluded from this rule because [...]"

Here, my question is whether in this scope, `operator()` should be considered to be a built-in operator.
Since to me, such one should instead be considered more of a normal function call.
Otherwise, it would undermine the rule's actual intention, which is to diagnose any unused return values of function calls, am I right?
Especially for modern C++ where plenty of code gets put into lambdas and/or std::function.

I would very happy if you could share some thoughts about this.

Thanks a lot in advance & best regards,
Stephan

Print this item

  A18-9-4
Posted by: cgpzs - 15-10-2024, 09:58 AM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Hi!

I wonder if this code example technically violates A18-9-4?

Code:
#include <memory>

struct Foo
{
    explicit Foo(int);
};

int main()
{
    int val{};
    auto x = std::make_unique<Foo>(val);
    ++val; // non-compliant?
}

Since internally, std::make_unique takes the input arguments as "Args&&..." and std::forward's them into the constructor of the class.

Thanks!

Print this item

  MISRA 2023 Test Suite
Posted by: grigdon - 14-10-2024, 01:27 PM - Forum: General Questions - No Replies

Hi,

Is there a MISRA 2023 test suite? I'm looking for C code with violations to be used for static analysis tool validation.

Thanks

Gerry

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,183
» Latest member: booini
» Forum threads: 1,004
» Forum posts: 2,768

Full Statistics

Online Users
There are currently 48 online users.
» 0 Member(s) | 45 Guest(s)
Bing, DuckDuckGo, Google

Latest Threads
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
13-01-2025, 10:58 AM
» Replies: 0
» Views: 63
MISRA AC SLSF:2023 AMD3
Forum: MISRA AC resources
Last Post: misra-ac
13-01-2025, 10:57 AM
» Replies: 0
» Views: 59
Rule 7.0.4 - exception fo...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:26 PM
» Replies: 4
» Views: 476
rule 7.0.5: clarification...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 02:11 PM
» Replies: 1
» Views: 127
Rule 7.0.6 - why the requ...
Forum: 4.7 Standard conversions
Last Post: misra cpp
10-01-2025, 01:24 PM
» Replies: 1
» Views: 85
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
20-12-2024, 02:38 PM
» Replies: 2
» Views: 477
Rule 7.0.2: Unclear/quest...
Forum: 4.7 Standard conversions
Last Post: misra cpp
20-12-2024, 02:24 PM
» Replies: 1
» Views: 350
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: misra cpp
20-12-2024, 02:05 PM
» Replies: 1
» Views: 356
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 932
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 731