Welcome to the MISRA discussion forum

Given the headline text of MISRA C++ 2008 Rule 6-1-1, MISRA C++ 2023 Rule 9.6.2 seems to be the equivalent rule in this case. MISRA C++ 2023 Rule 9.6.2 includes the following non-compliant example: 

• Quote:For the purposes of this rule, a switch-clause that does not consist of a compound statement is treated as if it were a block.

  
  

Could you please clarify to me if this violates 11.9:

Hi,

Rule 9.4.2 requires every switch statement to have a default clause, to match handling of if/else. However, unlike an if/else statement, this has a very serious implication: it prevents the compiler from warning about explicitly unhandled enumerators:

The rationale of the rule says:

> Also, some string handling functions only report errors through the use of errno

But that't not the case for std:: strerror, it does not report any errors through errno, nor is it possible for it to "read beyond the bounds of an object passed as a parameter", so it's perfectly safe to use it.

An alternative is to use std::make_error_condition(static_cast<std::errc>(errno)).message(), but it seems like overkill just to achieve the same thing, making the code far less readable.

It's also worth noting that MISRA does not ban the usage of errno (besides the restriction from 22.4.1), which is required for using POSIX functions that don't have any equivalent in the Standard Library.

Would you agree?

Rule 7.0.5 presents this example:

It is possible to add the 'try' statement directly after 'while', for example:

class Exception{};
void f(int i)
{
    while(i) try {             // Non-compliant
        //...
    } catch(Exception e){
    }
}

I think this is non-compliant with the Rule 9.3.1, because 'try' is not a compound statement. However, accordingly to the standard 'try' should be always followed by a compound statement if it is inside a function. This code seems to be clear, so maybe this case could be added as an exception in the future versions of MISRA C++ standard.

Hi,

Rule 16.6.1 marks this example as non-compliant:

The rule provides this example as Non-Compliant:

Appendix C (C.1.1, p. 270 (hard copy) / p. 271 (pdf)*) of MISRA C:2023 (3rd Edn, 2nd Rev., April 2023) reads:
"... as the examples below show (si and ui are 32-bit signed and unsigned integers and u8 is an 8-bit unsigned char):"

However, there is a lack of correspondence between the above-introduced unsigned char object identifier of u8 and the naming of an operand of unsigned char type in the table that follows immediately (viz. uc, columns Expression and Notes). On page 273(274) (C.2.4, a distinct sub-section of the Appendix) such an unsigned char object of similar name is indeed used (u8a), in line with the exemplary non-specific object names used in code fragments throughout the Guidelines' body of text (the naming convention introduced on p. 14).

For the sake of ease of visually perceiving the types involved in the expressions and following through the implicit conversions they undergo, it is a good decision that concise, plain names such as si, ui, and uc are used, instead of operand identifiers cluttered with numeric characters (as would be in s32(i32), u32 and u8).

Apparently, this lack of correspondence between the operand names in the table and their prior introduction in the text is inherited from the previous versions of the Guidelines (MISRA C:2012 – 3rd Edn, March 2013; 3rd Edn, 1st Rev., February 2019). Never corrected by subsequent Technical Corrigenda or Amendments to those. It is now present in MISRA C:2025 as well.

Please, consider appending the erratum, reported in this separate forum thread†, to the dedicated MISRA C Errata list maintained on the MISRA website, to keep it up-to-date and indeed a readily available single source of reference for all misprints found in MISRA C:2023, 3rd Edn, 2nd Rev.

_____

(*) Note that the text starts to disagree with the page numbering of the two documents (the electronic one and the hard copy) beginning from p. 229 onwards! This does not make favour to coherently referencing parts of the Guidelines and may lead to confusion and misunderstanding.

(†) This thread is considered the most relevant one as Appendix C is referenced mostly in there, and as there are no dedicated threads specifically aimed at the appendices, or some other general means for reporting typographical and other errors.

In Rule A3-3-2, there's an example with "class A" which has a non-constexpr, user-defined constructor. 

On line 31, we have a compliant example: