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

Username
  

Password
  





  is a cast compliant with Rule 12.4
Posted by: sowisojh - 30-09-2024, 08:25 AM - Forum: 8.12 Expressions - Replies (1)

Is the cast in the following code compliant with MISRA2023 Rule 12.4, assuming a machine having int as 32 bit?


Code:
#include <stdint.h>

#define USEFUL_BIT ((uint16_t)0x0020u)

uint16_t clear_useful_bit(uint16_t bitmask)
{
  uint16_t cleared_mask = bitmask;

  cleared_mask &= (uint16_t)~USEFUL_BIT;

  return cleared_mask;
}

According to Appendix D.7.5 1.1 the result of ~ is the UTRL of the result. Assuming an 32 bit integer machine this would be 4294967263u. The result of the cast to uint16_t would be perform a "repeatedly [...] subtracting one more than the maximum value that can be represented in the new type until the value is in the new type" which leads to 65503.

Is this type conversion treated as "unsigned integer wrap-around" in the sense of Rule 12.4 ?

Print this item

  Do any other forms of conditional inclusion violate Directive 5.7.2?
Posted by: rg99 - 27-09-2024, 11:21 AM - Forum: 4.5 Lexical conventions - Replies (1)

In particular, which of the following violates Directive 5.7.2?

Code:
#if 0
#endif

#if 0U
#endif

#if '\0'
#endif

#if 1 - 1
#endif

#if MACRO * 0
#endif

#if MACRO1 - MACRO2
#endif

Print this item

  Rule 0.1.9 - is zero-initialization considered "dead code"?
Posted by: cgpzs - 25-09-2024, 07:22 AM - Forum: 6.0 Language independent issues (C++) - Replies (3)

Consider the following example:

Code:
// third_party.h
struct Foo
{
   int32_t a;
   int32_t b;
};

// client.cpp
Foo create()
{
  Foo f{};     // Violates Rule 0.1.9?
  f.a = 123;
  f.b = 321;
  return f;
}

Does that violate Rule 0.1.9? While the initialization may be redundant, it serves a purpose as defensive programming. If we remove the zero-initialization, we risk having some members of "Foo" uninitialized, especially if we bump to a new version of "third_party.h" that adds a new member to the struct. It's safer to zero-initialize at the declaration, to ensure no members remain uninitialized.

It's also preferable to initialize like this instead of "Foo f{123, 321};", because we can see written in code which field gets which value. We need to wait until C++20 to get designated initializers in C++ to initialize everything in one line.

Thanks!

Print this item

  About MISRA-C 2023 Permit
Posted by: nghia do - 18-09-2024, 11:53 AM - Forum: General Questions - Replies (3)

Hi,

I would like to know when MISRA C:2023 permit is published. If no, could I understand there is no new deviation rule between MISRA-C 2012 and MISRA-C 2023

Print this item

  Rule 7.0.4 - example not compliant with 7.0.5?
Posted by: cgpzs - 12-09-2024, 12:56 PM - Forum: 4.7 Standard conversions - Replies (2)

Hi,

Rule 7.0.4 provides this example as compliant, and does not violate other rules  (like other examples)

Code:
static_cast< uint16_t >( u8 + u16 ) << 2;  // Compliant

Why doesn't this example violate 7.0.5? Bit shift applied on uint16_t will cause integral promotion from uint16_t to int, thus violating 7.0.5, or?

Thanks!

Print this item

  Rule 6.7.1 and thread storage duration
Posted by: rg99 - 10-09-2024, 06:40 PM - Forum: 4.6 Basic concepts - Replies (1)

Is Rule 6.7.1 intended to apply to local variables with thread storage duration?  For example:

Code:
typedef int int32_t;

void foo() {
    static int32_t var1{0};        // Non-compliant
    thread_local int32_t var2{0};  // Compliant ???
    /* ... */
}


While the rule specifically references "static storage duration" it is not clear what the intended impact of this rule is with respect to "thread storage duration" variables.  While local variables with thread storage duration do not suffer the same intrinsically thread-unsafe characteristics as those with static storage duration, the provided Rationale still applies.  In particular, they decrease comprehensibility, introduce temporal coupling, and can result in (reentrant) data races.

Print this item

  Rule 6.9.2: Unclear interpretation about "char"
Posted by: cgpzs - 03-09-2024, 07:52 AM - Forum: 4.6 Basic concepts - Replies (1)

Hi,

Rule 6.9.2 says it applies to "integral types constructed using the keywords char, ...". 
But it also says "it does not apply to the use of plain char".

This is confusing - is "char" allowed or not? Can you provide an example that shows where "char" is allowed and where it's not? I cannot find any in the rule explanation.

Thanks!

Print this item

  Rule R7.0.1 converting constructor question
Posted by: gdavis - 22-08-2024, 07:58 PM - Forum: 4.7 Standard conversions - Replies (1)

Hello,

Rule 7.0.1 allows for an explicit cast from bool to T when T has a converting constructor with a parameter of type bool. The example for the rule shows:

struct A
{
  explicit A ( bool );
};

A anA { true };       // Compliant - constructor

Yet, C++ requires a converting constructor to be non-explicit.

I'm not sure what the intent is, but perhaps the rule should allow for an explicit cast from B to T when T has an explicit constructor that takes a single parameter, a parameter of (possibly const-qualified) type bool.

Please advise. Thank you.

Print this item

  9.4.2 - Why C-style enums are exempted from requiring a default clause?
Posted by: cgpzs - 22-08-2024, 06:03 PM - Forum: 4.9 Statements - Replies (3)

Rule 9.4.2 requires that all switch blocks have a "default" case, for defensive programming.

This is however not required when using C-style enums, i.e. unscoped and without underlying type. Presumably because it's Undefined Behavior to cast an int out-of-range to a C-style enum, whereas it's well-defined behavior for "C++ enums". Since UB is assumed to not happen, one can assume that a C-style enum has a valid value.

However, there's a subtlety. The "range" of a C-style enum is not just the list of valid enumerators, but the smallest bitset that contains all enumerators.

So for example:

Code:
enum Foo
{
   a = 0,
   b = 1,
   c = 2,
   d = 3
};

The following code is **not** Undefined Behavior, because the valid range of this enum is 0-7 (2^3 - 1).

Code:
enum Foo x = static_cast<Foo>(7);

So I'd argue that defensive programming still applies here and a "default" case would still be needed.

What do you think?

Print this item

  A27-0-1 Unclear scope of the rule
Posted by: cgpzs - 20-08-2024, 10:36 AM - Forum: AUTOSAR C++:2014 rules - Replies (1)

Hi,

Rule A27-0-1 says:

Rule A27-0-1 (required, implementation, non-automated)
Inputs from independent components shall be validated.

This is very abstract and vague:

* What is the definition of "independent components"?
* Validated, in what context? When doing what?

The rule is in the section "Input/output library", and the code examples of this rule only talk about string manipulation/formatting functions. Can we therefore assume that this rule is only concerned with validating input passed to string manipulation/formatting functions?

Thanks!

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,232
» Latest member: MarcLG
» Forum threads: 1,029
» Forum posts: 2,844

Full Statistics

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

Latest Threads
21.18 is a safe strncpy f...
Forum: 8.21 Standard libraries
Last Post: dunno
20-08-2025, 08:47 AM
» Replies: 1
» Views: 1,835
Rule 10.1.1
Forum: 4.10 Declarations
Last Post: misra cpp
08-08-2025, 01:21 PM
» Replies: 1
» Views: 198
Rule 6.8.4 clarification ...
Forum: 4.6 Basic concepts
Last Post: kth
08-08-2025, 08:06 AM
» Replies: 0
» Views: 107
Rule 0.1.2 - missing exce...
Forum: 4.0 Language independent issues
Last Post: kth
07-08-2025, 10:07 PM
» Replies: 0
» Views: 120
Rule 6.7.2 variable templ...
Forum: 4.6 Basic concepts
Last Post: misra cpp
01-08-2025, 11:49 AM
» Replies: 1
» Views: 163
MISRA AC SLSF:2023 AMD4 a...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
29-07-2025, 08:34 AM
» Replies: 0
» Views: 157
MISRA AC SLSF:2023 AMD4
Forum: MISRA AC resources
Last Post: misra-ac
29-07-2025, 08:10 AM
» Replies: 0
» Views: 139
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
18-07-2025, 12:03 PM
» Replies: 3
» Views: 1,668
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: misra cpp
18-07-2025, 12:01 PM
» Replies: 3
» Views: 1,534
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: misra cpp
18-07-2025, 12:01 PM
» Replies: 3
» Views: 1,584