[cfe-dev] Distinguish between array parameters and pointer parameters in the AST.

[steve naroff]

On Feb 20, 2009, at 12:31 PM, steve naroff wrote:

>
> On Feb 20, 2009, at 12:22 PM, Roberto Bagnara wrote:
>
>> steve naroff wrote:
>>> On Feb 20, 2009, at 11:26 AM, Paolo Bolzoni wrote:
>>>> dear cfe list,
>>>>
>>>> According to the clang AST the two parameters' type of this  
>>>> function
>>>> declaration are the same:
>>>>
>>>> int f(int a[], int* b);
>>>>
>>>> while it makes sense, I'd like to distinguish.
>>>> Is it not possible?
>>>>
>>> Not currently. Here is a comment from  
>>> Sema::Sema::ActOnParamDeclarator():
>>>  // Perform the default function/array conversion (C99  
>>> 6.7.5.3p[7,8]).
>>>  // Doing the promotion here has a win and a loss. The win is the  
>>> type for
>>>  // both Decl's and DeclRefExpr's will match (a convenient  
>>> invariant for the
>>>  // code generator). The loss is the orginal type isn't preserved.  
>>> For example:
>>>  //
>>>  // void func(int parmvardecl[5]) { // convert "int [5]" to "int *"
>>>  //    int blockvardecl[5];
>>>  //    sizeof(parmvardecl);  // size == 4
>>>  //    sizeof(blockvardecl); // size == 20
>>>  // }
>>>  //
>>>  // For expressions, all implicit conversions are captured using the
>>>  // ImplicitCastExpr AST node (we have no such mechanism for  
>>> Decl's).
>>>  //
>>>  // FIXME: If a source translation tool needs to see the original  
>>> type, then
>>>  // we need to consider storing both types (in ParmVarDecl)...
>>>  // HTH,
>>
>> Thanks Steve.  In our case we need to see the original type: there  
>> are
>> coding rules that we need to check where the distincion is crucial.
>> For instance:
>>
>> int f(int a[], int* b) {
>>   a[0] = 0;     /* Compliant. */
>>   b[5] = 0;     /* Not Compliant: as b was not declared as an array,
>>                                   MISRA rule 17.4 is violated.  */
>> }
>>
>> How difficult would be to address the FIXME above?
>
> Actually, I think it's already been done:-)
>
> See OriginalParmVarDecl, which is a subclass of ParmVarDecl.
>
> Does this solve your problem?
>

I re-read my response and realized I was a bit too terse.

We use OriginalParmVarDecl for ObjC (to preserve the original type for  
meta-data generation).

The same idiom could be used to solve your problem without increasing  
the memory overhead for ParmVarDecl's in general.

snaroff

> snaroff
>
>
>
>>
>> Best,
>>
>>   Roberto
>>
>> -- 
>> Prof. Roberto Bagnara
>> Computer Science Group
>> Department of Mathematics, University of Parma, Italy
>> http://www.cs.unipr.it/~bagnara/
>> mailto:bagnara at cs.unipr.it
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090220/27d138bb/attachment.html>