Welcome to the MISRA discussion forum

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:

There has been a discrepancy between MISRA C and MISRA C++ for some years now* concerning the modal verbs used with respect to the guideline categorization. It would be informative for the user of these Guidelines to understand what were the original reasons behind that and why this is still the case. Is it only a matter of distinct Working Groups (which nevertheless share/d some common members), has it to do with maintaining legacy, or something else entirely?

But the more concerning question is, is it planned for future MISRA C editions to adopt the more nuanced wording of the MISRA C++ Guidelines with respect to the guideline categories of "Mandatory", "Required", "Advisory", and "Disapplied"?

Currently, established convention for each of the two documents is such that a guideline is introduced through their respective summary (requirement (MISRA C) / headline (MISRA C++) text) employing one of the following modal verbs, subject to the guideline category (M/R/A/D)†:

• MISRA C : "shall", "shall", "should", "should"
  
• MISRA C++‡ : "must", "shall", "should", n/a§
  

Are there any formal plans/estimates/roadmaps for adding c23 support to MISRA?
If work for this has already begun, how is it going? 

Dear MISRA group,

I have a question regarding the interpretation of the one-definition-rule in the presence of weak linkage (i.e. __attribute__((weak))).
In particular, is it considered a violation of the odr rule/rule 6.2.1 if a function with "strong" linkage "overrides" a function with "weak" linkage (as typically found in (standard) libraries)?

A special case within this discussion are global allocation and deallocation functions. The C++ standard calls them explicitly "replaceable".
Implementation-wise in any standard library I know, this is expressed by the weak linkage attribute.
Since the standard allows these few functions to be replaced explicitly, I conclude this does not constitute a violation of the one-definition-rule.

But how about any other weak-linkage function?

Thanks in advance!

We have some interesting cases for Rule 3-4-1 which we aren't sure whether they are violations or not. Strictly adhering to the rule of reduced visibility could cause issues regarding lifetimes, initialization, and side effects of a constructor/destructor.

For instance, in the following example, is the intent to require changes to the code so that 'old_value' is not visible after the if body, or is `old_value` considered non-violating?

Our static analyzer is complaining about our move constructor because we are not moving the entire "oth" input. Instead, we are doing member-wise move, in compliance with A12-8-1:

Rule A7-2-1 seems copied verbatim from the MISRA C++ 2008 rules. However, there's a key difference: C++14 has scoped enums. There, it is not unspecified (nor undefined) to cast an integer to the enum type when it is not any of the enumerators, since the valid range for the enum is the range of the underlying type. 

Based on that, what would be the rationale for keeping A7-2-1 in the AUTOSAR C++14 rules?

This document explains the structure of, and relationships between, the MISRA Autocode Guidelines (MISRA AC) family of documents. It is based on the original version, 1.0, published in 2007. The document has undergone extensive revision to reflect the changes in the MISRA AC document family and related standards, and the advances in use and awareness of modelling and automatic code generation approaches since that time.

Attached Files

  MISRA AC INT V2.pdf (Size: 173.88 KB / Downloads: 5)