[expr.const.cast] Changing qualifiers with pointers to arrays when casting away constness is forbidden

[Halalaluyafail3]

Full name of submitter (unless configured in github; will be published with the issue): Jay Ghiron

Reference (section label): [expr.const.cast]/6

Issue description:

Consider whether or not reinterpret_cast<const int**>((const int(*)[])0) is valid, which requires that the type const int(*)[] does not cast away constness in a conversion to the type const int** due to [expr.reinterpret.cast]/2. This has three possible values of n for different-qualification decompositions to consider with T1 being const int(*)[] and T2 being const int**:

• n=0, cv₀¹ and cv₀² are both empty, U₁ is the type const int(*)[], and U₂ is the type const int**. Changing each cv_i¹ to cv_i² has no effect here, so a qualification conversion is valid.
• n=1, cv₀¹ and cv₀² are both empty, P₀¹ and P₀² are both "pointer to", cv₁¹ is either const or empty, cv₁² is empty, U₁ is either the type int[] or the type const int[], and U₂ is the type const int*. If [conv.qual] Adding const with pointers to arrays in the qualification-combined type #987 is resolved as not allowing U₁ to be the type const int[] then U₁ is definitely the type int[] and cv₁¹ is definitely const. Otherwise, if U₁ is the type int[] then cv₁¹ must be const. If U₁ is the type int[] then changing cv₁¹ to cv₁² does have an effect here and causes the qualification conversion to be invalid. If U₁ is the type const int[] and cv₁¹ is empty then changing each cv_i¹ to cv_i² has no effect here, so a qualification conversion is valid. If U₁ is the type const int[] and cv₁¹ is const then changing cv₁¹ to cv₁² removes the const but it is unclear whether or not the const is actually removed from the resulting type because U₁ is still const, so it is unclear whether or not the qualification conversion is valid.
• n=2, cv₀¹ and cv₀² are both empty, P₀¹ and P₀² are both "pointer to", P₁¹ is "array of unknown bound of", P₁² is "pointer to", cv₁¹ and cv₂¹ are either both empty or both const, cv₁² is empty, cv₂² is either const or empty, U₁ is either the type int or const int, and U₂ is either the type int or const int. If [conv.qual] Adding const with pointers to arrays in the qualification-combined type #987 is resolved as not allowing either U₁ or U₂ to be the type const int, then U₁ and U₂ are definitely both the type int. Otherwise, if U₁ is the type int then cv₁¹ and cv₂¹ must both be const, and if U₂ is the type int then cv₂² must be const (this second if is not intended to be dependent upon the first if). If U₁ is the type int and cv₂² is const then changing cv₁¹ to cv₁² removes the const but it is unclear whether or not the const is actually removed from the resulting type because cv₂¹ is still const, so it is unclear whether or not the qualification conversion is valid. If U₁ is the type int and cv₂² is empty then changing cv₁¹ and cv₂¹ to cv₁² and cv₂² respectively does have an effect here and causes the qualification conversion to be invalid. If U₁ is the type const int and cv₁¹ and cv₂¹ are both empty then changing each cv_i¹ to cv_i² has either no effect or redundantly adds const, so a qualification conversion is valid. If U₁ is the type const int and cv₁¹ and cv₂¹ are both const then changing cv₁¹ to cv₁² removes the const and changing cv₂¹ to cv₂² removes a second const if cv₂² is empty but it is unclear whether or not the const is actually removed from the resulting type because U₁ is still const and if cv₂² is const then the const of cv₁² will remain, so it is unclear whether or not the qualification conversion is valid.

Second, consider the whether or not the reverse reinterpret_cast<const int(*)[]>((const int**)0) is valid. This has three possible values of n for different qualification-decompositions to consider with T1 being const int** and T2 being const int(*)[]:

• n=0, cv₀¹ and cv₀² are both empty, U₁ is the type const int**, and U₂ is the type const int(*)[]. Changing each cv_i¹ to cv_i² has no effect here, so a qualification conversion is valid.
• n=1, cv₀¹ and cv₀² are both empty, P₀¹ and P₀² are both "pointer to", cv₁¹ is empty, cv₁² is either const or empty, U₁ is the type const int*, and U₂ is either the type int[] or the type const int[]. If [conv.qual] Adding const with pointers to arrays in the qualification-combined type #987 is resolved as not allowing U₂ to be the type const int[] then U₂ is definitely the type int[] and cv₁² is definitely const. Otherwise, if U₂ is the type int[] then cv₁² must be const. In any scenario changing each cv_i¹ to cv_i² has no effect here or adds const, so a qualification conversion is valid.
• n=2, cv₀¹ and cv₀² are both empty, P₀¹ and P₀² are both "pointer to", P₁¹ is "pointer to", P₁² is "array of unknown bound of", cv₁¹ is empty, cv₂¹ is either const or empty, cv₁² and cv₂² are either both empty or both const, U₁ is either the type int or const int, and U₂ is either the type int or const int. If [conv.qual] Adding const with pointers to arrays in the qualification-combined type #987 is resolved as not allowing either U₁ or U₂ to be the type const int, then U₁ and U₂ are definitely both the type int. Otherwise, if U₁ is the type int then cv₂¹ must be const, and if U₂ is the type int then cv₁² and cv₂² must both be const (this second if is not intended to be dependent upon the first if). If cv₁² and cv₂² are both const then changing each cv_i¹ to cv_i² does have an effect here and causes the qualification conversion to be valid. If U₁ is the type int and cv₁² and cv₂² are both empty then changing cv₂¹ to cv₂² does have an effect here and causes the qualification conversion to be invalid. If U₁ is the type const int, cv₂¹ is empty, and cv₁² and cv₂² are both empty then changing each cv_i¹ to cv_i² has no effect here, so a qualification conversion is valid. If U₁ is the type const int, cv₂¹ is const, and cv₁² and cv₂² are both empty then changing cv₂¹ to cv₂² removes the const but it is unclear whether or not the const is actually removed from the resulting type because U₁ is still const, so it is unclear whether or not the qualification conversion is valid.

There is disagreement among implementations as to whether or not these casts are valid. What was the intent for these two cases? Specifically, if one const is removed from an array type in a qualification-decomposition of it where const is specified multiple times does that actually remove the const or does it need to be removed from all levels for the const to actually be removed?

[Halalaluyafail3]

Aside from these unclear cases of array types, it may also be useful to add wording to clearly define the behavior of when U₁ is a function type and cv_n² is not empty. For example reinterpret_cast<const void*>((void(*)())0), assuming that function pointer to object pointer conversions are allowed by the implementation. Though there does not seem to be any disagreement about how to handle this case. (There is disagreement about the reverse reinterpret_cast<void(*)()>((const void*)0) but that seems to be clearly invalid.)

[jensmaurer]

Can you please rephrase your analysis of expr.const.cast using the quoted representation of types, not the type-id variant?

I think the types to compare are "pointer to pointer to const int" and "pointer to array of unknown bound of const int". Note also that an array of cv-qualified type is itself cv-qualified.

[Halalaluyafail3]

Can you please rephrase your analysis of expr.const.cast using the quoted representation of types, not the type-id variant?

I think the types to compare are "pointer to pointer to const int" and "pointer to array of unknown bound of const int". Note also that an array of cv-qualified type is itself cv-qualified.

I did that by describing each cv_i^j, P_i^j, and U_i element, no? But the fundamental question is: what should happen when changing each cv_i¹ to cv_i² tries to create an array type that has different qualifiers than its element type?

[jensmaurer]

There's a large wall of text above.

Is there a suggested change to the existing standard wording hidden somewhere? Is there at least a desired outcome for the examples (which may or may not be reflected by the existing wording)?

[jensmaurer]

Since the crucial question here seems to be whether "cast away constness" is satisfied, which is defined by "there is no qualification conversion" from some time X1 to another type X2, it seems the question can be rephrased using "is there a qualification conversion from X1 to X2" for specific types X1 and X2. It would help to have these specific types written down.

And isn't this CWG2438 last point?

[Halalaluyafail3]

Since the crucial question here seems to be whether "cast away constness" is satisfied, which is defined by "there is no qualification conversion" from some time X1 to another type X2, it seems the question can be rephrased using "is there a qualification conversion from X1 to X2" for specific types X1 and X2. It would help to have these specific types written down.

And isn't this CWG2438 last point?

Not sure how that issue is related here. The issue here is not with the qualification conversion rules, but specifically about the meaning of how the qualifiers are copied over. For the first example (non-volatile is assumed for simplicity):

• T1 is "non-const pointer to const array of unknown bound of const int".
• T2 is "non-const pointer to non-const pointer to const int".
• The type described by [expr.const.cast]/6 is "non-const pointer to non-const array of unknown bound of const int" for n=2.

How should "non-const array of unknown bound of const int" be resolved? If that is known, then the validity of the qualification conversion should be clear.

Is there at least a desired outcome for the examples (which may or may not be reflected by the existing wording)?

I think the wording should specify in this case that the qualifier is removed from both the element type and the array type.