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

From: Julia Lawall
Date: Fri Nov 14 2014 - 04:19:22 EST




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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/