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

Username
  

Password
  





  It 8.12 intended to be so strict?
Posted by: Loïc - 25-06-2026, 10:05 PM - Forum: 8.8 Declarations and defnitions - Replies (1)

Hello,

It is clear by looking at the title of rule 8.12 

Quote:Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique

That the following code is non-compliant:

Code:
// Non-compliant, yellow has an implixitly defined value that it shares with last
enum colour { red, blue, green, yellow, last = yellow };

This is a relatively common pattern, and the alternatives seem worse.

It is the intent of this rule to prevent this pattern, or is it just a result of the wording?
By the way, this code is compliant with the C++ version of this rule in MISRA C++:2023.

Print this item

  10.3 Clarify if narrower in the title refers the the rank of the essential type
Posted by: Loïc - 25-06-2026, 09:03 PM - Forum: 8.10 The essential type model - Replies (1)

The rule 10.3 says:

Quote:The value of an expression shall not be assigned to an object with a narrower //essential type//

What does it mean to be narrower? To have a lower rank, or to have a smaller size?

For instance, on a platform where 
Code:
sizeof(long) == sizeof(long long)

Is the following code compliant with rule 10.3:
Code:
long l = 0;
long long ll = 0;
l = ll; // Compliant or not?

My feeling is that it is compliant, because the word rank is not used here, while it is explicitly used in other parts of the rule, but I'm not 100% confident.

Print this item

  What is the UTLR of -1?
Posted by: Loïc - 09-06-2026, 09:36 AM - Forum: 8.10 The essential type model - Replies (1)

I'm attempting to determine the essential type of the following expression:

Code:
(unsigned short)1 - (unsigned short)2

This is a operation subject to arithmetic conversion (D.7.9), both operands are essentially unsigned, and the expression is an integer constant expression, so according to item 4.1, the essential type of the result is the UTLR of the result.

However, the result is a signed integer with the value -1. The following program demonstrates this:
Code:
#include <stdio.h>


#define TYPE(x) _Generic((x), \
    int: printf("int\n"), \
    unsigned int: printf("unsigned int\n"), \
    default: printf("other\n") \
)

int main() {
    TYPE(1u - 2u); 
    TYPE(1 - 2); 
    TYPE((unsigned short)1 - (unsigned short)2);
}



So we have to compute the UTLR of a negative value, which is not defined.

Is there an error in my reasoning, or is this a limitation in the essential type system?

Print this item

  13.2 Was TC2 correctly applied to the rule in MISRA C:2023?
Posted by: Loïc - 03-06-2026, 03:27 PM - Forum: 8.13 Side effects - Replies (1)

Hello,

TC2 says:

Quote:TC 2.23 : In the “Amplification” section, number the existing two notes as 1 and 3 respectively.
TC 2.24 : In the “Amplification” section, insert a new note 2 between the existing two notes: 2. All parts of the expression are considered when determining whether an object is read or modified, irrespective of any known values

But when looking at MISRA C:2023, we only see 2 notes, and the text that was supposed to be inserted as node 2 appears in second position in the bullet list above the notes.

Which is right? The TC2, or the 2023 version?

Thank you,

Print this item

  Rule 6.5.2: Missing exception for static class members?
Posted by: pwolf - 02-06-2026, 07:14 AM - Forum: 4.6 Basic concepts - Replies (1)

The wording of rule 6.5.2 seems to imply that any entity with internal linkage may not be declared static, even though the static keyword “also has other uses”.
With that interpretation, the rule would completely prohibit the use of static class members with internal linkage.

For example, given this code snippet:

Code:
static void F1() {} // 1

namespace {

static void F2() {} // 2

class Klass {
  public:
    static void F3() {} // 3
};

} // namespace


In cases 1 and 2, the static keyword is “inappropriate”. F1 should be declared inside the anonymous namespace instead and for F2 the static keyword could be simply dropped.
F3 has internal linkage but the static is not used for linkage but to make the function a class function. Still, the amplification of rule 6.5.2 says that internal linkage of an entity is only appropriate if it’s not declared static, which F3 clearly is.

Is that intentional? Should the wording be improved to make it clear that only static declarations which could affect linkage are considered?
Or (to simplify static analysis) could an exception be added for static class members?

Print this item

  AUTOSAR C++14 M5-2-10 for unique_ptr in combination with ++ operator
Posted by: kth - 08-05-2026, 08:51 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

The AUTOSAR C++14 Guidelines  ("AUTOSAR Guidelines for the use of the C++14 language in critical and safety-related systems") contain the MISRA C++:2008 rule 5-2-10 as rule M5-2-2. M5-2-2 was modified to required but - AFAIK - nothing else was changed.

Quote:Rule M5-2-10 (required, implementation, automated)
The increment (++) and decrement ( ) operators shall not be mixed with other operators in an expression.

There is a similar MISRA C:2012/2023/2025 rule 
Quote:Rule 13.3 A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator

Also some examples are shared:
Code:
u8a = ++u8b + u8c--;  // Non-compliant
// The following sequence is clearer and therefore safer:
++u8b;
u8a = u8b + u8c;
u8c--;


While this makes makes sense for C and C++, there are differences between C and C. What about the following code:

Code:
#include <cstdint>
#include <memory>


struct Data {
        std::int32_t member;
};

std::int32_t main(){
        std::unique_ptr<Data> d = std::make_unique<Data>(12);
        d->member++;  // Compliant ?
}

Shall a AUTOSAR C++14/MISRA C++:2008 checker report a violation for  "d->member++" or is that OK?

Print this item

  Rule about extern "C" and missing exceptions
Posted by: kth - 04-05-2026, 04:24 PM - Forum: 4.6 Basic concepts - Replies (1)

Currently, MISRA C++:2023 mentions "extern C" as part of the following rules:

  • title of Rule 6.0.3 (The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations),
  • exception 2 of Rule 10.2.1,
  • amplification and rationale of Rule 18.4.1 and
  • as part of different examples (e.g., in Rule 19.0.3)

However, until now there is no rule provided that limits the keywords etc. can be "safely" used inside of an extern "C" block.

Wouldn't that be helpful?

Examples:
  • what happens when I define a namespace inside of an extern "C" block?
  • what happens when I define or declare (accidentally) a class in an extern "C" block?
  • what happens when I use a C++ reference in a function signature like "int foo(int& in_out)"?
  • Basics: the C compiler does not know extern "C". Consequently, it should be surrounded by ´#ifdef __cplusplus´ and ´#endif´.
  • ...

What about exceptions for extern "C" in the rules
  • 11.3.1 (Variables of array type should not be declared) as in an extern C block a std::array is not available.
  • 10.2.2 (Unscoped enumerations should not be declared) - notice that for 10.2.1 an exception si defined

Code example (https://godbolt.org/z/EG7Y9dxdh):
Code:
// some header.h - shared between C and C++

#ifdef __cplusplus
#include <cstdint>
#else
#include <stdint.h>
#endif

#ifdef __cplusplus
extern "C" {
#endif

  typedef int MyInt;  /* likely OK */

  void foo();  /* likely not OK */

  struct X { int a; };  /* is this OK? */ 

  struct Y { int32_t b; };  /* or this? */ 

  struct Z { char c[3]; };  /* or this? */ 

  namespace dummy {  /* and this? */
 
    class C {  /* or this - note: maybe the #ifdes __cplusplus guard is missing ...  */
    public:
      int val{2};
    };

  }

#ifdef __cplusplus
}
#endif


// c++ code

int main() {
 
  dummy::C c1;

  return c1.val;
}

Print this item

  Rule 6.0.3 and extern "C"
Posted by: kth - 04-05-2026, 03:12 PM - Forum: 4.6 Basic concepts - Replies (1)

Rule 6.0.3 has the title

Quote:The only declarations in the global namespace should be main, namespace declarations and extern "C" declarations

However, with the current MISRA C++:2023 version the amplification does not contain details about the extern "C" declarations and there are no  examples that use  an extern "C" block.

My question first question: is it OK to use typdefs in extern "C" blocks and also in the global namespace to be able to share these typdefs between C and C++ code?

Example:

Code:
#ifdef __cplusplus
#include <cstdint>
#else
#include <stdint.h>
#endif

#ifdef __cplusplus
extern "C" {
#endif

typedef uint16_t AddressType_t;  /* Compliant? (to be able to share typdefs in C and C++ code this is OK) */

void foo();                      /* Compliant? ('foo' needs C linkage and it is OK to have a C function in the global namespace) */

#ifdef __cplusplus
}
#endif


Second question: As the rule explicitly mentions extern "C" declarations - what else is allowed or not allowed? (What about, e.g., struct definitions or function definitions?)

Print this item

  Rule 6.9.1 and (possibly) qualified identifiers / name lookup / namespaces
Posted by: ckaiser - 24-04-2026, 02:10 PM - Forum: 4.6 Basic concepts - Replies (1)

Hello,

We are wondering how Rule 6.9.1 shall be understood when namespaces and name lookups are involved.
Rule's rationale is about avoiding confusion. But, especially, the examples only address very basic (mis)uses, i.e., using obviously different type (alias) names in (re-)declarations. Very C-like...

It is unclear, when it comes to (namespace) qualification and (re-)introducing names into namespaces or scopes.
Under those conditions, it becomes fuzzy what is meant with "the same type alias": Is it just the spelling of the name (including qualification)? Is it the definition, i.e. resulting the underlying type? Or, is it the same qualified name (regardless how it was spelled in code - i.e., whether and how it was qualified)?
Maybe, it even is (or should be) out of scope of rule 6.9.1?


Example:

Code:
namespace n {
struct S {};
using Alias = S;
Alias foo(); // (0)
S bar();
}

auto n::foo() -> Alias; // (1)
n::Alias n::foo(); // (2) with leading return type I have to use the namespace.

using Alias = n::Alias;
auto n::foo() -> Alias; // (3)
Alias n::foo(); // (4)

namespace m {
class Klass {
public:
    using S = n::S;
    using Alias = n::S;
    friend Alias n::foo(); // (5)
    friend S n::bar(); // (6)
    explicit Klass(n::S const&);
};

using n::S;
auto Klass(S const&); // (7)
}
First observation: It doesn't seem to be always about type aliases, but about the question, wich type (name) will be eventually used. This might be out of scope of Rule 6.9.1, but it is still related to developer's expectation / possible confusion.

Note: to keep the examples simple, I'd judge "compliance" always only considering any difference to the initial declaration, e.g., (0).
(In practice, one violating declaration probably would cause the whole set of declarations being not compliant.)

(1): Is most definitely compliant, as both indeed use the very same type alias, in all respects.
(2): Compliant? It "names" the same alias, but it is "spelled" (i.e., it looks) differently. Might lead to confusion?
(3): Compliant? Maybe; which alias will be used? Should it matter in this case?
(4): Compliant? Same (unqualified) name ist used, but in the end it is a different alias, still resulting in the same type. Regarding the underlying type, one could argue, it is still the same alias.
(5): Compliant? Similar to (4); just to demonstrate a friend declaration.
(6): Compliant? Original declaration didn't even use a type alias - maybe, not even in scope? Still same "name".
(7): Compliant? IMO, actually not in scope, because type aliases are not used in any declaration of that entity.


Personally, I don't have a strong opinion on that. I just found declarations of those kinds in our codebase. Thus, I'm asking for clarification.
IMHO, using same names (qualified or unqualified) seems to match expectations it could be okay, as long as they do result in same types.
Mixing different qualifications within one scope (class or namespace) is quite confusing as well (such as (1) and (2), even though namespace qualification is required for (2))

Thank you very much,
Best regards.

Print this item

  11.6 pointer to pointer to void
Posted by: dunno - 17-03-2026, 08:43 PM - Forum: 8.11 Pointer type conversions - Replies (2)

Hi, does this rule apply also for pointer to pointer to void?

Code:
void * ptr;

uint32_t addr = (uint32_t)&ptr;

or does this code violate any of the other rules?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,309
» Latest member: 1fuhd
» Forum threads: 1,066
» Forum posts: 2,933

Full Statistics

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

Latest Threads
13.2 Was TC2 correctly ap...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:47 PM
» Replies: 1
» Views: 621
20.12 Does the stringific...
Forum: 8.20 Preprocessing directives
Last Post: misra-c
08-10-2026, 12:40 PM
» Replies: 1
» Views: 550
13.3 Should side effects ...
Forum: 8.13 Side effects
Last Post: misra-c
08-10-2026, 12:37 PM
» Replies: 1
» Views: 422
11.6 pointer to pointer t...
Forum: 8.11 Pointer type conversions
Last Post: misra-c
08-10-2026, 12:21 PM
» Replies: 2
» Views: 1,028
What is the UTLR of -1?
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 12:15 PM
» Replies: 1
» Views: 596
10.3 Clarify if narrower ...
Forum: 8.10 The essential type model
Last Post: misra-c
08-10-2026, 11:57 AM
» Replies: 1
» Views: 502
It 8.12 intended to be so...
Forum: 8.8 Declarations and defnitions
Last Post: misra-c
08-10-2026, 11:50 AM
» Replies: 1
» Views: 448
Rule 0.1.1 Example f4
Forum: 4.0 Language independent issues
Last Post: cgpzs
07-10-2026, 11:07 AM
» Replies: 3
» Views: 716
Rule 6-2-2 Usage of std::...
Forum: 6.6 Statements (C++)
Last Post: misra cpp
25-09-2026, 05:43 PM
» Replies: 1
» Views: 431
M5-0-4 switch over unscop...
Forum: 6.5 Expressions (C++)
Last Post: misra cpp
25-09-2026, 01:00 PM
» Replies: 3
» Views: 525