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

Username
  

Password
  





  Compiler - minimal test suite
Posted by: delirium5223 - 04-09-2025, 12:16 PM - Forum: General Questions - No Replies

It would be nice if MISRA specified a mandatory C/C++ compiler minimal test-suite package to be run against production compiler.

If your compiler is claimed to be C99 compliant, then you shouldn't be worried about not passing.

We have seen so many buggy compilers (e.g. I remember Microchip miscompiling u32 on 8bit code that ran fine in IAR on 32bit)

If we cannot trust the compiler then we can argue about MISRA rules all day, the hidden bugs will remain to be found either by testing or by end user.

It will never be perfect nor exhaustive, but we could raise the minimum bar at least.

Print this item

  named vs positional initialization
Posted by: delirium5223 - 04-09-2025, 11:27 AM - Forum: 8.9 Initialization - No Replies

What do you think about advising against using mixed aggregate initialization, named vs positional.

When mixing them there is a higher chance for human confusion/mistake. e.g. not covering all of them etc



Code:
typedef struct
{
  int x;
  int y;
  int z;
} TypeA;

void test4(void)
{
  TypeA obj = { .y = 2, 3 }; // nok mixed aggregate initialization, named vs positional
  TypeA obj2 = { 3 , .y = 2 }; // nok
  TypeA obj3 = { 3 , 2, 4 }; //ok, not mixed
  TypeA obj4 = { .x = 3 , .z = 4, .y = 2 }; //ok, not mixed
}

Rule 9.6 only prohibits them when they are embedded structs, not for single struct.

Code:
/* Non-compliant - chained designators and implicit positional initializers mixed */
struct T tt = {
1,
.s.x = 2, /* To a human reader, this looks like .z is being initialized */
3, /* tt is actually initialized as { 1, { 2, 3 }, 0 } */
}; /* This also violates Rule 9.2 */

Print this item

  Gaps in enums
Posted by: delirium5223 - 04-09-2025, 11:06 AM - Forum: General Questions - No Replies

Can we have a new rule that says 

Quote:  if enum is used as an iterator type then there shall not be gaps in enum values.




Code:
typedef enum
{
  PIN_A = 1, 
    //missing 2
  PIN_B = 3,
  PIN_C = 4,
  PIN_MAX,
} tPin;
 
for(tPin i = PIN_A ; i < PIN_MAX; i++) 
{
// i reaching 2 is unintended/refactoring/human error
}

Surely we would want to know/acknowledge that enum has a gap if we plan to iterate over it.
(regardless where the 'for' loop starts/end)
   
It would make a good higher level/abstraction rule.
 
Or at least make it advisory.

Print this item

  Rule 13.3 incr/decr op in initialization
Posted by: delirium5223 - 04-09-2025, 10:55 AM - Forum: 8.13 Side effects - No Replies

Based on the example in MISRA 2023 C this is non-compliant:

Code:
  int u8a=0;  // implied
  u8a = u8b++;  //don't accept assignment and increment on the same line

  but what about in initialization? According to PCLP tool it's acceptable:
Code:
  int u8a = u8b++;

My view is that de/increment shouldn't be mixed with anything and it should be alone in one line to avoid any chance of confusion.

Please clarify.

Print this item

  Rule 11.6.1 - Variables initialized via output-parameter?
Posted by: cgpzs - 02-09-2025, 11:26 AM - Forum: 4.11 Declarators - No Replies

Hi,

Consider the following example:

Code:
// external_c_api.h
enum error_t
{
  // ...
};

enum foo_t
{
  foo_A = 1,
  foo_B = 2
};

error_t externalCApi(foo_t*);

// main.cpp
void f()
{
  foo_t x;
  error_t error = externalCApi(&x);
}

How would one apply 11.6.1 in this case? It's not possible to avoid the two-step initialization process. There may not even be a "sensible default" to give to `x` before giving it the "real" value (and MISRA explicitly discourages this pattern). In particular, doing "foo_t x{};" leads to zero initialization, but there is no enumerator with the value 0.

Thanks!

Print this item

  Rule 6.8.4 clarification of amplification
Posted by: kth - 08-08-2025, 08:06 AM - Forum: 4.6 Basic concepts - Replies (1)

The amplification of rule 6.8.4 leads with this sentence to clarify to which member functions this rule applies:

Quote:This rule applies to member functions with reference or pointer return type, where, in the definition of the function, at least one
return expression explicitly designates this, *this or a subobject of *this.

The usage of the word “designates” here is ambiguous.
Does it mean the expression . . .

  1.  . . . is (or evaluates to something that is) this, *this or a subobject of *this?
  2.  . . . refers/points to (or evaluates to something that refers/points to) this, *this or a subobject of *this?
  3.  . . . contains this, *this or a subobject of *this in any shape or form?
  4. A combination of the above?

Depending on which interpretation is true, the following code examples are either
compliant or non-compliant:

Code:
class A {
std::int32_t data_;
public:
// returns a pointer to data member
std::int32_t const* Get() const { return &data_; }
};

class B {
std::int32_t* ptr_;
public:
// returns data member which is a pointer to an
// object with lifecycle independent of "this"
std::int32_t* Get() const { return ptr_; }
};

class C {
std::int32_t idx_;
public:
// returns unrelated pointer based on data member
float const* Get(std::array<float,10> const& data) const { return &data[idx_]; }
};

The intent of the rule seem to support meaning number 2, which would mean only A::Get is non-compliant.
If that is the case, we suggest to replace “designates” with a less ambiguous phrase, e.g. “references/points to” or to explain more clearly what is meant in the amplification.
In addition, clarifying examples for these cases would be helpful.

Print this item

  Rule 0.1.2 - missing exceptions and advisory ?
Posted by: kth - 07-08-2025, 10:07 PM - Forum: 4.0 Language independent issues - Replies (1)

Hi,

The amplification of MISRA C++:2023 rule 0.1.2 states that “This rule only applies when the function is called explicitly using function call syntax”.
Consequently, operators like “+=” are out of scope so in the following code the modification of the std::string object with “+=” is fine and the usage of append, without checking the returned reference, is a violation of this required rule:

Code:
void example1() {
    // Non-compliant use of std::string::append
    std::string my_string;
    my_string.append("foo");  // add 'foo'
    my_string.append("bar");  // add 'bar'
}

void example2() {
    // Compliant use of std::string::operator+=:
    std::string my_string;
    my_string += "foo";  // add 'foo'
    my_string += "bar";  // add 'bar'
}

void example3() {
    std::vector<int> numbers;

    numbers.push_back(1);  // Compliant to MISRA C++:2023 Rule 0.1.2
                           // as push_back ""returns"" void

    // C++ reference: https://en.cppreference.com/w/cpp/container/vector/push_back.html

    // emplace_back returns (since C++17) an iterator:
    // https://en.cppreference.com/w/cpp/container/vector/emplace_back.html

    numbers.emplace_back(2);  // Non-compliant to MISRA C++:2023 Rule 0.1.2 (since C++17)
}

The function append of std::string (std::basic_string) and the operator+= append additional characters to the end of the string. Both return a reference to “*this”. Both throw std::length_error if the operation would cause size() to exceed max_size() and provide the strong exception safety guarantee. So, there is no real difference between using “+=” or “append” in terms of safety or code quality. If one wants to write compliant code, example1 needs to be refactored to use a void cast  to ignore the result:

Code:
void example1_compliant_version() {
    std::string my_string;
    static_cast<void>(my_string.append("foo"));  // add 'foo'
    static_cast<void>(my_string.append("bar"));  // add 'bar'
}

That would implicitly force developers to always prefer operators like “+=” over functions like “append” as the alternatives make the code harder to read or lead to additional effort (deviations need to be justified).

If one decides to rework this kind of code to a “fluent API style” that could lead to extra copies:
Code:
std::string BuildFailureMsg(std::string_view name, std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    msg.append("Component ");
    msg.append(name);
    msg.append(" failed due to ");
    msg.append(reason);
    msg.append("\n");
    return msg;
}
std::string BuildFailureMsgNaiveRefactor(std::string_view name,
                                      std::string_view reason) {
    std::string msg{};
    msg.reserve(name.size() + reason.size() + 26);  // reserve sufficient memory
    return msg.append("Component ")
        .append(name)
        .append(" failed due to ")
        .append(reason)
        .append("\n"); // will create and return copy of msg (i.e. see extra "memcpy")
}
int main() {
    std::string failure_msg_01 = BuildFailureMsg("Logger", "insufficient memory");  // no copies/moves
    std::string failure_msg_02 = BuildFailureMsgNaiveRefactor("Logger", "insufficient memory");  // extra copy
}

Consequently, existing code that uses append needs to be refactored to use “+=”. A huge refactoring effort for large code bases, but without any real benefit.
Also, it might lead to the negative effect that developers that uses std::vector prefer “push_back” over “emplace_back”, as with C++17 std::vector::emplace_back returns a reference (example3). Other alternatives might lead to less efficient code. 

Our questions:
  1.       Is it really intended to promote the usage of operators over functions and (for std::vector and other std-library types like std::optional::emplace) to use push_back over emplace_back or are here just exceptions missing?
  2. As the rationale states that “it is possible to call a function without using the return value, which may be an error”, should this rule be changed to “advisory” and the title changed to “The value returned by a function should be used”.
  3. Independent of 1 and 2: should an additional exception for functions that use C++ exceptions to report errors added?

Print this item

  Rule 10.1.1
Posted by: Merge - 04-08-2025, 07:59 AM - Forum: 4.10 Declarations - Replies (1)

Hi,

We are having a discussion with one of our tool vendors about how to interpret MISRA C++ 2023 rule 10.1.1, more concretely, the impact of the implicit 'this' parameter. I won't say which party supports which interpretation for the sake of neutrality.

Example code:
https://godbolt.org/z/hxz4bzvan


Interpretation A)
Fn() has an implicit, non-const 'this' parameter, so the rule is violated (Fn() should have been declared const).


Interpretation B)
Fn() does not have any parameters, so the rule is not violated.


We would appreciate an unbiased opinion to settle this discussion.

Best regards,
Daniel "Merge" Merget

Print this item

  MISRA AC SLSF:2023 AMD4 available
Posted by: misra-ac - 29-07-2025, 08:34 AM - Forum: MISRA AC SLSF discussions - No Replies

MISRA AC SLSF:2023 Amendment 4 (which contains modifications that bring the guidelines up to date for MATLAB release R2025a) is now available as a free download from the "MISRA AC resources" section of this Bulletin Board.

Print this item

  MISRA AC SLSF:2023 AMD4
Posted by: misra-ac - 29-07-2025, 08:10 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 R2025a. It includes required statuses of new diagnostics and revisions to the statuses of some library blocks and configurations.



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

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,237
» Latest member: mr li
» Forum threads: 1,034
» Forum posts: 2,851

Full Statistics

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

Latest Threads
Compiler - minimal test s...
Forum: General Questions
Last Post: delirium5223
04-09-2025, 12:16 PM
» Replies: 0
» Views: 587
named vs positional initi...
Forum: 8.9 Initialization
Last Post: delirium5223
04-09-2025, 11:27 AM
» Replies: 0
» Views: 582
Gaps in enums
Forum: General Questions
Last Post: delirium5223
04-09-2025, 11:06 AM
» Replies: 0
» Views: 306
Rule 13.3 incr/decr op in...
Forum: 8.13 Side effects
Last Post: delirium5223
04-09-2025, 10:55 AM
» Replies: 0
» Views: 274
Rule 11.6.1 - Variables i...
Forum: 4.11 Declarators
Last Post: cgpzs
02-09-2025, 11:26 AM
» Replies: 0
» Views: 720
Rule 6.8.4 clarification ...
Forum: 4.6 Basic concepts
Last Post: misra cpp
24-08-2025, 03:26 PM
» Replies: 1
» Views: 737
Rule 0.1.2 - missing exce...
Forum: 4.0 Language independent issues
Last Post: misra cpp
24-08-2025, 03:23 PM
» Replies: 1
» Views: 741
21.18 is a safe strncpy f...
Forum: 8.21 Standard libraries
Last Post: dunno
20-08-2025, 08:47 AM
» Replies: 1
» Views: 2,458
Rule 10.1.1
Forum: 4.10 Declarations
Last Post: misra cpp
08-08-2025, 01:21 PM
» Replies: 1
» Views: 763
Rule 6.7.2 variable templ...
Forum: 4.6 Basic concepts
Last Post: misra cpp
01-08-2025, 11:49 AM
» Replies: 1
» Views: 709