[cfe-dev] A doubt about cvr-qualified array types.

[Abramo Bagnara]

Il 23/10/2010 19:09, Eli Friedman ha scritto:
> On Sat, Oct 23, 2010 at 2:15 AM, Enea Zaffanella <zaffanella at cs.unipr.it> wrote:
>> Hello.
>>
>> We have a doubt regarding qualified array types.
>>
>> Consider the following program:
>> ===============================
>> struct S {
>>  int a[2];
>> };
>>
>> void foo(void) {
>>  const struct S* ps;
>>  const int (*b)[2];
>>  b = &ps->a;
>> }
>> ===============================
>> as well as its ast dump:
>> ===============================
>> struct S {
>>    int a[2];
>> };
>> void foo() (CompoundStmt 0x3c48bf8 <arraytype.c:5:16, line:9:1>
>>  (DeclStmt 0x3c1be20 <line:6:3, col:21>
>>    0x3c1bdd0 "const struct S *ps")
>>  (DeclStmt 0x3c1bf60 <line:7:3, col:20>
>>    0x3c1bf10 "const int (*b)[2]")
>>  (BinaryOperator 0x3c48bc8 <line:8:3, col:12> 'const int (*)[2]' '='
>>    (DeclRefExpr 0x3c1bf80 <col:3> 'const int (*)[2]' Var='b' 0x3c1bf10)
>>    (UnaryOperator 0x3c48ba0 <col:7, col:12> 'int const (*)[2]' prefix '&'
>>      (MemberExpr 0x3c48b30 <col:8, col:12> 'int const[2]' ->a 0x3c1bc10
>>        (DeclRefExpr 0x3c1bfb8 <col:8> 'const struct S *' Var='ps'
>> 0x3c1bdd0)))))
>> ===============================
>>
>> The dump shows a mismatch between the types of the lhs and the rhs of
>> the assignment expression:
>>  - the lhs has type    const int (*)[2]
>>  - the rhs has type    int const (*)[2]
>> that is, in the rhs the const qualifier is applied to the array type,
>> rather than to the array element type. The two types are anyway detected
>> as being equivalent as witnessed by the absence of an implicit cast.
> 
> Per C99, those are the same type.

To be exact C99 6.7.3.8 says something a little different:

"If the specification of an array type includes any type qualifiers, the
element type is so qualified, not the array type."

So it seems to exclude the existence of qualified array type...

>> We thought there was an implementation invariant whereby qualifiers of
>> array types, when stored in clang::Expr nodes, were automatically pushed
>> on the corresponding array element type.
>> Is this NOT the case?
> 
> For canonical types, yes... for non-canonical types, no.  The two
> types in question here should probably be fixed to print the same way,
> though... it's confusing to have what appears to be the same type
> print in different ways.

However, if the current behaviour is confirmed to be intentional, we
should taken in account that the type stored along with Expr nodes might
have qualifiers also in array type.

Does this means that we might encounter all the possible combinations
(i.e. element with qualified/unqualified type inside nested arrays with
qualified/unqualified type) and that the qualifiers of arrays types and
item type should be merged to get a "normalized" type (not canonical)
where qualifiers are pushed to the item type as standard mandates?

There is a method to get such type?