10.2.3 Amplification

[hahn]

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

Code:

enum E {E1, E2};
int f(int);
E operator+(E, E);
int main() {
  E e = E1;
  f(e); // Compliant? (1)
  e = e + e; // Non-compliant (2)
}

I wonder whether (1) should be compliant or not. At least it is not listed in the amplification, but seems like a problematic case anyway.
In turn, should (2) be non-compliant as operands to "arithmetic operator" are explicitly listed in the amplification, while I think this case is absolutely fine.

It would be great to get a clarification on what the rule intends.

[misra cpp]

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.

[hahn]

Thanks for your reply and the clarifications.
I have one more code example which reading the text appears non-compliant to me, but does not contradict the rationale or poses an issue in my view.

Code:

enum E e;
  E& eref = e; // Compliant or not?

There is a source of an assignment (variable initialization) of enum type, and the target type (E&) is neither the same enum type (but reference to it) or a sufficiently sized integer type.

A clarification once more would be great.

[misra cpp]

Your example is compliant, as the value of e is not being used.

The amplification says the rule applies to use 'as the source of an assignment', but reference binding is not assignment.
There may be subsequent non-compliances, depending on how eref is used, i.e. any place where the use of e would be non-compliant, is non-compliant if eref is used instead.

The rule should clarify that reference binding is not an assignment, and this will be added in the next version.