Actually, what result would you prefer?  In the previous fix that I made,
I just caused the missing type, which was hidden under a macro, to make
the match fail.  In this case, though perhaps you would prefer T to be
bound to int?  That might cause some problemes, though, because it is not
a real "int" in the source code...

julia

On Mon, 8 Apr 2013, Nic Volanschi (R&D) wrote:

> If this may help, I stumbled against the same error in a different setting, 
> but I think the ultimate cause is the same:
>
> $ cat in.c
> int foo()
> {
>   register rI;
>   return rI;
> }
>
> $ cat in.cocci
> @f1@
> identifier f;
> position p;
> type T;
> @@
> * T@p f;
>
> The reported error is the same: << Fatal error: exception Failure("empty 
> list, max_min_ii_by_pos") >>
> I localized the problem on the variable declaration <<register rI;>> where 
> the type is missing (int by default). As soon as
> you add the missing "int", the error disappears.
> In fact, the error seems somewhat justified, as you are taking the position 
> of an inexistent type.
>
> I guess that in the big file indicated by Markus, the problematic declaration 
> is:
>
> static DEFINE_PER_CPU(unsigned long, cpu_loops_per_jiffy) = { 0 };
>
>
> where we have the same missing, implicit int return type.
>
> Hope it helps,
> Nic.
>
> On Wed, 2013-04-03 at 12:00 +0200, [email protected] wrote:
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 02 Apr 2013 17:37:30 +0200
> From: SF Markus Elfring <[email protected]>
>
>
> Would you like to reproduce my issue with the following SmPL filter pattern on
> the source file
> "https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/init/calibrate.c?id=8595c539f0360477189eef91f6337b
> a44962f72d"?
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Apr 2013 18:21:22 +0200 (CEST)
> From: Julia Lawall <[email protected]>
>
>
> I get the problem on the following code:
>
> irqreturn_t
> nouveau_irq_handler(DRM_IRQ_ARGS)
> {
>         struct drm_device *dev = arg;
>         struct nouveau_device *device = nouveau_dev(dev);
>         struct nouveau_mc *pmc = nouveau_mc(device);
>         u32 stat;
>
>         stat = nv_rd32(device, 0x000100);
>         if (stat == 0 || stat == ~0)
>                 return IRQ_NONE;
>
>         nv_subdev(pmc)->intr(nv_subdev(pmc));
>         return IRQ_HANDLED;
> }
>
> I would suspect that there is some inconsistency in how it is parsing this
> kind of argument list.  It seems to parse it OK, but then not be able to
> match it against a pattern like ...,x,...  I can look at it in more detail
> tomorrow.
>
> julia
>
>
>
>
_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci

Reply via email to