[Cocci] Re: problems with typecasts

[Carl-Daniel Hailfinger]

On 05.03.2009 17:39, Julia Lawall wrote:
>>> If you really want to combine them, 
>>> you could say:
>>>
>>>
>>> (
>>> read
>>> |
>>> write
>>> )
>>>  (...,
>>> - (T)
>>>   b)
>>>
>>> (Note that there is a space before the ( in the sixth line)
>>>   
>>>       
>> Unfortunately, that semantic patch does not match any code with read
>> because read only takes one parameter and the pattern has a comma. If I
>> remove the comma from the pattern, spatch complains about invalid syntax.
>>     
>
> Did you try it?  Normally ..., matches no arguments as well.

Yes, I tried it. See below.

> I tried:
>
> @@
> identifier f;
> expression x;
> @@
> f(...,
> - x
> + 12
>  )
>
> and
>
> int main () {
>   f(1,2,3);
>   f(x);
> }
>
> and it updated both calls.
>   

I just found out why it didn't work: I directly copied your example
which used "write" and "read", although my code used "writeb" and
"readb". Sorry for the false alarm.


>>> For the problem with parentheses, a possibility is to do the following, 
>>> etc for the read case:
>>>
>>> - a = *(b)
>>> + a = readb(b)
>>>   
>>>       
>> Unfortunately, that won't work match the statement below because there
>> are no parentheses around b.
>> id2 = *(volatile uint8_t *)(bios + 0x01);
>>     
>
> This seems to work fine as well.  Again, the isomorphism ensures that *(b) 
> matches *b also.
>   

My apologies. This was worded the wrong way. Although the statement will
match, parenthesis removal will not happen in the special case listed above.

The semantic patch below gives me what I want, though.

@@
expression a;
typedef uint8_t;
volatile uint8_t *b;
@@
- *(b) = (a);
+ writeb(a, b);
@@
volatile uint8_t *b;
@@
- *(b)
+ readb(b)
@@
type T;
T b;
expression a;
@@
(
 readb
|
 writeb
)
 (...,
- (T)
- (b)
+ b
 )

The semantic patch above generates the following warnings:
warning: line 19: should readb be a metavariable?
warning: line 21: should writeb be a metavariable?
warning: rule starting on line 13: metavariable a not used in the - or
context code

Thank you for explaining the details and pointing out the bugs my
semantic patch had.

Regards,
Carl-Daniel