Re: [Cocci] spatch for trivial pointer comparison style?

[Julia Lawall <julia.lawall@lip6.fr>]

On Thu, 13 Nov 2014, Joe Perches wrote:

> On Fri, 2014-11-14 at 07:06 +0100, Julia Lawall wrote:
> > On Thu, 13 Nov 2014, Joe Perches wrote:
> >
> > > I added a checkpatch entry for this.
> > > Maybe some cocci test like this would be useful?
> > >
> > > @@
> > > type t;
> > > t *p;
> > > @@
> > > -	p == NULL
> > > +	!p
> > >
> > > @@
> > > type t;
> > > t *p;
> > > @@
> > > -	p != NULL
> > > +	p
> > >
> > > @@
> > > type t;
> > > t *p;
> > > @@
> > > -	NULL == p
> > > +	!p
> > >
> > > @@
> > > type t;
> > > t *p;
> > > @@
> > > -	NULL != p
> > > +	p
> >
> > This was discussed many years ago.  I don't think that the change is
> > desirable in all cases.  There are functions like kmalloc where NULL means
> > failure and !p seems like the reasonable choice.  But there maybe other
> > cases where NULL is somehow a meaningful value.
> >
> > Here is a link to the part of the discussion:
> >
> > https://lkml.org/lkml/2007/7/27/103
>
> Yes, I agree with some of the things Al Viro said
> there, but isn't 'type t; t *p;' a subset of
> "expression *e"?

No.  How would you expect it to be different.  type t means that the type
is known.  expression *e means that there is a * in the type.  But there
is no way to know that there is a * in the type without knowing the full
type.

Maybe something like

e = f(...);
...
if (e == NULL) S1 else S2

would be acceptable?  But I was thinking that for some functions NULL
might be considered to be a meaningful result, rather than a sign of
failure.

The following semantic patch gives almost 3000 results:

@disable is_null@
expression e;
statement S1,S2;
@@

e = \(kmalloc\|kzalloc\|kcalloc\|devm_kmalloc\|devm_kzalloc\)(...);
... when != e
if (<+...
- e == NULL
+ !e
    ...+>) S1 else S2

julia