Welcome to the MISRA discussion forum

MISRA-C 2012 D.3 states that UTLR/STLR rules are only applied to integer constant expressions for operators that explicitly specify this in D.7. D.7 further states that the essential type is the standard type unless otherwise listed and does not specify a non-standard essential type for sizeof.

This Amendment to MISRA AC SLSF:2023 contains modifications that bring the guidelines up to date for MATLAB release R2023b

Attached Files

  MISRA AC SLSF 2023 AMD1.pdf (Size: 444.31 KB / Downloads: 9)

Should the C++17 [[fallthrough]]; attribute be given an exception for MISRA C++ 2008 Rule 6-2-3 (a null statement shall appear on a line by itself)?

Hi,

I find the amplification of rule 10.2.3 confusing.

In general I wonder what the difference to a simple "no implicit conversion from unscoped enumeration type without underlying type to numeric type" (plus the exception for static_cast in bullet point 3) is?

In particular, as example, for the following code

```c
constexpr int32_t fn( int32_t i )
{
  return i * i;
}

u8 + fn( 10 )   // Compliant by exception #1
```

Is u8 a typo? Reasonable one might be 'u32 + fn(10)'?

Hi! I've questions about the examples of MISRA C++:2023 Rule 0.2.4 "Functions with limited visibility should be used at least once":

namespace B
{
  struct C2 {};
  static void swap( C2 &, C2 & ); // Non-compliant
}

B:wap() is marked as non-compliant, could anyone please give some explanations?

Thank you very much!

We would like to have some clarification regarding cvalues and integral constant expressions when considering C++14.

Main Question: Is N, which is an integral constant expression, a cvalue as defined in MISRA C++:2008?

We started looking at the new MISRA C++ 2023 guidelines and ways for us to migrate over from AUTOSAR C++14. However, since we have some embedded platforms for which C++17 compilers aren't available (yet), we'll have to apply some combination of AUTOSAR and MISRA until we can fully move over. In Loïc Joly's talk at NDC TechTown he mentioned e.g. the reasoning for getting rid of the single return rule. Does MISRA provide any documentation on such reasonings for other old MISRA/AUTOSAR rules? This would help us a lot in our effort to find an AUTOSAR C++14 subset which we could employ together with MISRA C++ 2023. Alternatively, do you know of any other efforts that are underway to apply MISRA C++ 2023 to C++14 platforms?

MISRA C++ rule 6.9.2 (The names of the standard signed integer types and standard unsigned integer types should not be used) defines two exceptions (shortened):
1. for type aliases 
2. postfix operator, return type of main and argc of main.

Currently, there is no exception for user-defined literals.

However, the C++ standard defines as part of  [over.literal] §16.5.8.3:

Hi.
Is it possible in C90, without violating MISRA Rule 6.1, to declare bitfields defined as an explicitly signed or explicitly unsigned integer type other than the unsigned int and signed int types allowed by the compiler?
According to section 8.6, this is allowed in C99. However, the compiler I use has a setting to accept the ANSI C dialect conforming to X3.159-1989. With this setting enabled, bitfields can have base types that are enumerated or integral types besides int and unsigned int. This matches A.6.5.8 in the ANSI Common Extensions appendix.
With this setting, I think the declaration of bitfields below is a permitted deviation. Is my understanding correct?