Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
10.2.3 Amplification
#2
Taking point (2) first,  you're right - as the rule is written this is non-compliant but doesn't violate the intent of the rule. We should possibly have made an exception for use in overloaded operators. However, we currently have no plans to change this, as it seems like a rather edge case and the user always has the options of deviating the rule for this usage. If we get more queries that suggest that this is a common use case, we'll reconsider.

For point (1), No this is non-compliant. Bullet 3 of the Amplification says such values 'shall not be used ... as the source of an assignment...'. Note that 'assignment' is in quotes, meaning it is being used as defined elsewhere in the document. The C++ standard defines contexts for the use of values: assignment, returning, passing as a parameter and initialisation.  MISRA rules usually apply to all four context, so rather than keep listing all four, somewhere we say 'for this document 'assignment' is taken to mean assignment, returning, passing as a parameter and initialisation'. Hence passing the enumeration value as a function parameter is 'assignment' as far as the rule is concerned.

We admit this could be clearer, so we intend to define a term 'general-assignment' in the glossary and modify all the rules that use 'assignment' to mean these four cases to use 'general-assignment'. 

The problem with  "no implicit conversion from unscoped enumeration type without underlying type to numeric type" is that we want to allow the use of enumeration types as an array index.
Posted by and on behalf of
the MISRA C++ Working Group
Reply


Messages In This Thread
10.2.3 Amplification - by hahn - 26-03-2024, 03:08 PM
RE: 10.2.3 Amplification - by misra cpp - 12-04-2024, 02:20 PM
RE: 10.2.3 Amplification - by hahn - 06-05-2024, 08:57 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)