On Wed, 10 Nov 2010, Vasiliy Kulikov wrote:

> On Wed, Nov 10, 2010 at 16:49 +0100, Julia Lawall wrote:
> > On Wed, 10 Nov 2010, Vasiliy Kulikov wrote:
> > 
> > > On Wed, Nov 10, 2010 at 16:28 +0100, Julia Lawall wrote:
> > > > It also occurred to me that in eg sizeof(*x), where x has type int *, 
> > > > the 
> > > > reference to *x is not really a reference to an integer value, and the 
> > > > reference to x is not really a reference to an integer pointer value.  
> > > > Thus there is no longer any type inference for the argument to sizeof.  
> > > > If 
> > > > this seems like a bad decision, please let me know and I will change it 
> > > > back.
> > > 
> > > Why?..  I don't see any troubles with it.  The only uniqueness of
> > > sizeof() is that it doesn't really calculates its argument, e.g. 
> > > after "int a = 1; sizeof(a++);" a is still 1, but AFAIU this should not
> > > influence on coccinelle.
> > 
> > I'm not clear on what you are suggesting.
> 
> Nothing ;)  I just didn't understand why you've chosen it.
> 
> > Suppose you have the following 
> > semantic patch:
> > 
> > @@
> > int x;
> > @@
> > 
> > - x
> > + ANINT(x)
> > 
> > and the code:
> > 
> > int x;
> > foo(sizeof(x));
> > 
> > Do you want to obtain:
> > 
> > int x;
> > foo(sizeof(ANINT(x)));
> > 
> > or:
> > 
> > int x;
> > foo(sizeof(x));
> 
> Maybe the script writer should more preciselly declare x's properties?
> Change all occurrences of int doesn't make much sense to me...

OK, good point.  It is probably only useful when testing whether size_t 
and int work properly :)

> > > But it is impossible to differ wrong type passing to memset:
> > > 
> > > struct X *ll;
> > > memset(ll, 0, sizeof(*ll));
> > > 
> > > vs.
> > > 
> > > struct X *ll; /* l + l */
> > > struct Y *l1; /* l + 1 (number one) */
> > > memset(ll, 0, sizeof(*l1));
> > 
> > OK, I guess.  But perhaps the above code would be wrong even if both ll 
> > and l1 had type struct X *?
> 
> OK, assume that ll is initialized :)

I still don't get the point.

julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)

Reply via email to