[cfe-dev] ArrayType and qualifiers

[Abramo Bagnara]

Il 28/01/2011 10:26, John McCall ha scritto:
> 
> On Jan 28, 2011, at 12:39 AM, Abramo Bagnara wrote:
> 
>> Il 28/01/2011 04:06, John McCall ha scritto:
>>>> Note that however also with current svn trunk we have a problem with
>>>> this test: the assignment x = y should be compiled without warning in
>>>> C++ *but* it's an assignment between incompatible pointers in C (clang
>>>> currently does not emit any warning on both C and C++).
>>>
>>> It's not an assignment between incompatible pointers in C.  y is a
>>> T*, where T = int[1];  converting that to the type of x (const T*) is
>>> a 6.3.2.3p2 pointer conversion.
>>
>> It seems you're definitely right.
> 
> Hmm.  Actually, I think I'm wrong. :)  In C, array types are never
> qualified, only their element types;  so while my argument is sound in
> principle, it's not actually following the specification.
> 
> That said, this is quite arguably a flaw in the specification, and it's
> been so argued in quite a few places, as mentioned and linked from here:
>   http://stackoverflow.com/questions/305293/constant-array-types-in-c-flaw-in-standard
> so we should probably add a -pedantic warning for this at least.  I've
> file http://llvm.org/bugs/show_bug.cgi?id=9082 to track this.

stackoverflow seems to refers to case of cast from pointer to int to
pointer of array of int, while the example I wrote is about

I don't see how 6.3.2.3p2 might be read differently from what you has
written in previous email.

Take this modified example:

void f() {
  const int (*x)[1] = 0;
  int (*y)[1] = 0;
  x = y;
}

typedef int Type[1];

void g() {
  const Type* x = 0;
  Type* y = 0;
  x = y;
}

6.3.2.3p2 says: For any qualifier q, a pointer to a non-q-qualified type
may be converted to a pointer to the q-qualified version of the type;
the values stored in the original and converted pointers shall compare
equal.

I really don't think that the standard C99 want to do an exception for a
specific instance of Type... (or at least I hope so ;-)

>> I believe the case is different here: for every other type the
>> qualifiers stripping is local and has no effect on inner types, for
>> arrays the qualifier stripping in array alter the interpretation of
>> inner nodes (I think that RecursiveASTVisitor will suffer of this).
> 
> That's true.
> 
>> However I think that we will proceed changing our visitors to save the
>> array qualifiers for later reapplication to element type.
> 
> Thank you.  I'm sorry to keep changing the AST out from under you;  we
> really do think this is the right technical design.

Don't be sorry, every good technical choice about AST is very welcome
for us and I've already adapted our code to restore qualifier position
where standard mandates, so everything is working again.

I've written to convince myself this was indeed a good technical choice
and to be honest I've still doubts for some techinical reasons:

1) incongruence on representations of canonical types and syntactical
type about position of qualifiers

2) the element type AST node has not the qualifiers that standard mandates

3) asimmetry about treatment of ComplexType and VectorType wrt ArrayType
(the qualifiers are where standard mandates in both canonical and syntactic)

4) fragile clang API, where we risk everytime to lose element qualifiers
descending on the type

Now that I'm sure you know our perspective I can stop to pester you ;-)