Welcome to the MISRA discussion forum

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.

MISRA is very pleased to announce the release of the new version of MISRA C++; MISRA C++:2023 Guidelines for the use C++:17 in critical systems

Published in October 2023, this is the latest and current edition of MISRA C++. It is specifically targetting the 2017 language version (C++:17) as defined by ISO/IEC 14882:2017.

The document is available in PDF form from our webstore, and you can also purchase hardcopies using a “print on demand” service.

We will create an FAQ section shortly with answers to questions on the new document as well as a new area in this forum for discussion on its guidelines. Please wait until we have created the new forum topics before posting questions.

Webstore purchases are for single-user individual licenses. Other uses including but not limited to corporate (shared) use, use within a tool by tool vendors and training courses require a license; details are available on request. Please use the "contact us" form on the MISRA website to get in touch.

In our first project with MISRA we have a question.
 
The couple of “issues” with MISRA 2012 rule 13.5:
 
Variables:
volatile uint8_t bMakeAlarm; (from interrupt)
uint8_t bRelay;
uint8_t bCountSW2High;
uint8_t bPlayerPlaying;
 
Info: SW2 = (PORTA.IN & (uint8_t)PIN5_bm) is a “register” (CPU)
 
Original if statement
 
if (SW2 == 0U || bMakeAlarm != 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  do_something;
}
 
This makes the message 13.5 because bMakeAlarm is volatile.
 
If I change it a little bit to (removing the volatile):
 
if (SW2 == 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This complies with MISRA. However if change it to this which is normally basically the same:
 
if (bRelay != 0U || SW2 == 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This not comply with 13.5, why?
 
Like in recommendations for the rule 13.5 this will work:
 
SW2hold = SW2;
bMakeAlarmHold = bMakeAlarm;
   
if (bRelay != 0U || SW2hold == 0U || bMakeAlarmHold != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
What is the best solution?
But not super readable and could lead to faults if you do not remember that the xxxHold is just a temp. Any other good work-a-rounds?

Thanks 

Please note the following error in rule MISRA AC GMG 011 of some impressions of MISRA AC GMG:2023:

The text

     Only the four relational operators: ">", "<", ">=" and "=" may be used for comparing floating-point values

should instead read

     Only the four relational operators: ">", "<", ">=" and "<=" may be used for comparing floating-point values

The rule 10.8 states that "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

I understand that casting to a wider type will cause incompatibilities for different compilers where int have different width, but I don't understand why we cannot cast it to a different essential type category with the same or less width. 

In other words, the example

Hi

A4-5-1 states:

Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.

A3-9-1 forbids the use of char (and a recent question clarifies that it's intended for signed/unsigned char).

However, how can we create storage in that case, since we don't have std::byte until C++17? We could use `std::uint8_t`, but that's not the type that is used in the Standard, and could potentially not be identical to "unsigned char" depending on platform.

Example use case:

Understanding that assembler code has to be documented and isolated (Directives 4.2 & 4.3 ), are there any limits to how much assembly code there is in a project? Could you have have a project that is mostly assembly with only C wrappers and yet still claim MISRA compliance?