Re: [Cocci] [PATCH 1/4] Coccinelle: Restore coccicheck verbosity in ONLINE mode (C=1 or C=2)
On 2.3.2013 22:36, Nicolas Palix wrote: A recent patch have introduce the VERBOSE variable and comments now depend on it. However, the message printed for each cocci file such not be printed when the ONLINE mode is active, whatever is the value of VERBOSE. Signed-off-by: Nicolas Palix nicolas.pa...@imag.fr --- scripts/coccicheck |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I applied these four to kbuild.git#misc. Michal ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Analysis for Linux source files
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 (RD) 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, cocci-requ...@systeme.lip6.fr wrote:
--
Message: 1
Date: Tue, 02 Apr 2013 17:37:30 +0200
From: SF Markus Elfring elfr...@users.sourceforge.net
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 julia.law...@lip6.fr
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
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Handling of omitted data type specification?
In the previous fix that I made, I just caused the missing type, which was hidden under a macro, to make the match fail. How do you think about to make this detail configurable? In this case, though perhaps you would prefer T to be bound to int? Does the C programming language specify that integers are used as the default data type (or if modifiers are used)? http://stackoverflow.com/questions/2099830/unsigned-keyword-in-c#2099873 https://www.cs50.net/resources/cppreference.com/data_types.html http://en.cppreference.com/w/cpp/language/types That might cause some problemes, though, because it is not a real int in the source code... Does the semantic patch language support to filter for omitted data types? Would you like to distinguish the use case if this item was just forgotten or intentionally omitted? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Handling of omitted data type specification?
On Mon, 8 Apr 2013, SF Markus Elfring wrote: In the previous fix that I made, I just caused the missing type, which was hidden under a macro, to make the match fail. How do you think about to make this detail configurable? On this case, there is nothing to configure. If there is no known type, then matching a type variable cannot succeed. In this case, though perhaps you would prefer T to be bound to int? Does the C programming language specify that integers are used as the default data type (or if modifiers are used)? http://stackoverflow.com/questions/2099830/unsigned-keyword-in-c#2099873 https://www.cs50.net/resources/cppreference.com/data_types.html http://en.cppreference.com/w/cpp/language/types Coccibelle already takes case of eg signed x; It should do the same for register, for consistency. That might cause some problemes, though, because it is not a real int in the source code... Does the semantic patch language support to filter for omitted data types? Would you like to distinguish the use case if this item was just forgotten or intentionally omitted? Perhaps it is useful. There may be an isomorphism for deciding whether or not int is assumed in the signed etc case. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
