Welcome to the MISRA discussion forum

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?

Hello, 
I saw in a previous post (https://forum.misra.org.uk/showthread.php?tid=1302), it was discussed that 

We have now added discussion forums for the MISRA C++:2023 guidelines. If your question is specifically about the 2023 (C++17) version of MISRA C++ then please post in these forums.

The forums are grouped by the major sections of MISRA C++:2023. So for example if your question is about Rule 9.4.2 on the structure of a switch statement, then post it under 4.9 Statements.

The MISRA C++ Working Group will monitor posts and reply in due course where necessary, please remember we are all volunteers so replies may not be instant.