Hi !
minor glitch in the rc18 release (or should it be rc17 ?)
after downloading coccinelle-1.0.0-rc18.tgz unpacking and
compile/installing it on Debian wheezy it shows up as rc17
root@Xil:~# tar -xzf coccinelle-1.0.0-rc18.tgz
root@Xil:~# cd coccinelle-1.0.0-rc18/
root@Xil:~/coccinelle-1.0.
On Fri, 29 Nov 2013, Julia Lawall wrote:
> On Fri, 29 Nov 2013, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > minor glitch in the rc18 release (or should it be rc17 ?)
> > after downloading coccinelle-1.0.0-rc18.tgz unpacking and
> > compile/ins
On Fri, 29 Nov 2013, Julia Lawall wrote:
> On Fri, 29 Nov 2013, Arie Middelkoop wrote:
>
> > What is written in the "version" file in your coccinelle dir?
> > The tarball on the coccinelle website does have version rc18, so if you
> > have that
> > one, it cannot have invented rc17 out of thin a
On Fri, 29 Nov 2013, Peter Senna wrote:
> As a "workaround", I did before running ./configure:
>
> aclocal -I m4 --install
> autoconf
>
> then:
>
> ./configure
> make all
>
> then:
>
> ./spatch --version
> spatch version 1.0.0-rc18 with Python support and with PCRE support
>
> I've tested th
HI !
Trying to scan for a problem that was recently found in the acpi code.
static void advance_transaction(struct acpi_ec *ec, u8 status)
{
unsigned long flags;
struct transaction *t = ec->curr;
spin_lock_irqsave(&ec->lock, flags);
if (!t)
goto
On Fri, 27 Dec 2013, Julia Lawall wrote:
> > @assign@
> > expression s,var;
> > position p1,p2,p3;
> > statement S1;
> > identifier func,member;
> > @@
> >
> > ...func@p1(...){
>
> You don't need the ... before func. I guess you were worried about the
> return type, visibility modifiers, etc.
HI !
while building rc21 ./configure outputs
...
optimized spatch: no(overridable with --disable-opt)
...
which should probably be --enable-opt ?
thx!
hofrat
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/
quot; access to freed objects see drivers/staging/rts5208/trace.h
Acked-by: Julia Lawall
Signed-off-by: Nicholas Mc Guire
---
scripts/coccinelle/free/kfree.cocci |2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/coccinelle/free/kfree.cocci
b/scripts/coccinelle/free/kfree.cocci
i
is added to the list of calls
"protecting" access to freed objects see drivers/staging/rts5208/trace.h
Acked-by: Julia Lawall
Signed-off-by: Nicholas Mc Guire
---
scripts/coccinelle/free/kfree.cocci |2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/coccinelle/free/k
HI !
make coccicheck in 3.16++
is failing on Debian 7.6 with
make coccicheck MODE=report -C /usr/src/linux-stable/ M=/usr/src/read_msr
make[1]: Entering directory `/usr/src/linux-stable'
Please check for false positives in the output before submitting a
patch.
When using "patch" mode, careful
On Sun, 28 Sep 2014, Julia Lawall wrote:
> On Sun, 28 Sep 2014, Nicholas Mc Guire wrote:
>
> >
> > HI !
> >
> > make coccicheck in 3.16++
> > is failing on Debian 7.6 with
> >
> > make coccicheck MODE=report -C /usr/src/linux-stable/ M=/usr/src/re
On Sun, 28 Sep 2014, Julia Lawall wrote:
> On Sun, 28 Sep 2014, Nicholas Mc Guire wrote:
>
> > On Sun, 28 Sep 2014, Julia Lawall wrote:
> >
> > > On Sun, 28 Sep 2014, Nicholas Mc Guire wrote:
> > >
> > > >
> > > > HI !
> > > &
On Mon, 01 Dec 2014, Francois Berenger wrote:
> On 12/01/2014 11:12 AM, Francois Berenger wrote:
>> Hello,
>>
>
> Instead of applying ...
>
>> Inside of applying any patch, I need to use coccinelle
>> in order to detect certain C files that match a given pattern
>> in a source code tree.
>>
>> Is
Hi !
writing some cocci file to detect some completion related
issues - for the function cases it works fine. If its correct
I'm not sure. What the first one should be doing is
find any siutation where a completion is reinitialized
with init_completion rather than reinit_completion.
so fin
On Tue, 23 Dec 2014, Julia Lawall wrote:
> On Tue, 23 Dec 2014, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > writing some cocci file to detect some completion related
> > issues - for the function cases it works fine. If its correct
> > I'm
On Tue, 23 Dec 2014, Julia Lawall wrote:
> > > > first working case:
> > > > ===
> > > >
> > > > @c@
> > > > expression cmp;
> > > > position p;
> > > > @@
> > > >
> > > > init_completion@p(cmp)
> > > >
> > > > @d@
> > > > expression E,c.cmp;
> > > > identifier f;
> > > > position
> > > >
> > > > because that would match cases like
> > > >
> > > > init_completion(cmp)
> > > > wait_for_completion(cmp)
> > > > init_completion(cmp)
> > >
> > > Doesn't this match the "first working case" rule?
> > >
> >
> > yes - just not sure if the first case is exhaustive - only
> > if it
On Tue, 23 Dec 2014, Julia Lawall wrote:
> > Fatal error: exception Failure("meta: parse error:
> > = File "false_declare_completion.cocci", line 27, column 14, charpos = 511
> > around = 'DECLARE_COMPLETION', whole content = declarer name
> > DECLARE_COMPLETION;
> > ")
> > ...
>
> OK, it'
On Tue, 23 Dec 2014, Julia Lawall wrote:
>
>
> On Tue, 23 Dec 2014, Nicholas Mc Guire wrote:
>
> > On Tue, 23 Dec 2014, Julia Lawall wrote:
> >
> > > > Fatal error: exception Failure("meta: parse error:
> > > > = File "fal
On Wed, 24 Dec 2014, Julia Lawall wrote:
> > will update to rc23 and retest - can this be a config/python version issue ?
> > python version is 2.7.3 (Debian 7.6)
>
> I have Python 2.7.5+
>
> > > For the performance problem, could you send the current semantic patch
> > > again, so I could be su
On Wed, 24 Dec 2014, Julia Lawall wrote:
>
>
> On Wed, 24 Dec 2014, Nicholas Mc Guire wrote:
>
> > On Wed, 24 Dec 2014, Julia Lawall wrote:
> >
> > > > will update to rc23 and retest - can this be a config/python version
> > > > iss
Reviewed-by: Andreas Platschek
Signed-off-by: Nicholas Mc Guire
---
.../coccinelle/api/duplicate_init_completion.cocci | 59
1 file changed, 59 insertions(+)
create mode 100644 scripts/coccinelle/api/duplicate_init_completion.cocci
diff --git a/scripts/coccinelle/api
This little set of semantic patches is for partially checking the
completion API. It seems to be working correctly and has not yet
produced any false-positive.
The cases being detected are:
1/3 - duplicate init_completions.
2/3 - incorrect static initialization of completion on stack.
3/3 - re-i
Reviewed-by: Andreas Platschek
Signed-off-by: Nicholas Mc Guire
---
scripts/coccinelle/api/false_init_compltion.cocci | 74 +
1 file changed, 74 insertions(+)
create mode 100644 scripts/coccinelle/api/false_init_compltion.cocci
diff --git a/scripts/coccinelle/api
Reviewed-by: Andreas Platschek
Signed-off-by: Nicholas Mc Guire
---
.../coccinelle/api/false_declare_completion.cocci | 50
1 file changed, 50 insertions(+)
create mode 100644 scripts/coccinelle/api/false_declare_completion.cocci
diff --git a/scripts/coccinelle/api
catch useless conditionals like (1 == 1) or (1 != 0) - it seems like some
code generators like this "style"
Signed-off-by: Nicholas Mc Guire
---
After stumbling across this code in drivers/media/dvb-frontends/dib7000p.c
value = 0;
if (1 != 0)
value
On Tue, 05 May 2015, SF Markus Elfring wrote:
> > Check if the signature of a function and the return value type match.
>
> Is this a task that is usually performed by a compiler?
>
>
> > In many cases this mismatch will have no side-effects
> > but in some cases it may lead to hard to locate p
On Tue, 05 May 2015, Julia Lawall wrote:
> > +@match@
> > +identifier f,ret;
> > +position p;
> > +type T1,T2;
> > +@@
> > +
> > +T1 f(...) {
> > + T2 ret;
> > +<+...
> > +* return@p ret
> > +;
> > +...+>
> > +}
>
> Given the number of results, it may seem surprising, but I think that you
> are a
helpful when types match.
Signed-off-by: Nicholas Mc Guire
---
Did not see any false positives in a scan of 4.0-rc2 (but did not check
all results either).
Not sure if scripts/coccinelle/tests/ is the right place for this
It did not seem to trigger any false positives but in some cases (notably
On Tue, 05 May 2015, Julia Lawall wrote:
>
>
> On Tue, 5 May 2015, Nicholas Mc Guire wrote:
>
> > On Tue, 05 May 2015, Julia Lawall wrote:
> >
> > > > +@match@
> > > > +identifier f,ret;
> > > > +position p;
> > > >
Hi all !
Trying to do type checking on calls within functions and
ran into the problem that I'm unable to create disjoint rules for
those functions that assigne their return value to a variable and
those that do not. The reason why this is need (I think atleast)
is because in the first rule the
On Thu, 07 May 2015, ZhouYuan wrote:
>Hi,
>I have met many problems when I try to use the clause of "when".
>For example, I want to check whether there is an default statement in
>switch, I wrote the Semantic Patch as following:
>
> @rule@
> function F;
> position p
On Sat, 09 May 2015, SF Markus Elfring wrote:
> > @hascase@
> > position p;
> > @@
> > switch@p (...)
> > {
> > case...:...
> > }
> >
> > @hasdefault@
> > @@
> > switch (...)
> > {
> > default:...
> > }
> >
> > @script: python depends on hascase && !hasdefault@
> > p< > @@
> > print "%s %s" %
On Sat, 09 May 2015, Julia Lawall wrote:
>
>
> On Sat, 9 May 2015, Nicholas Mc Guire wrote:
>
> > On Thu, 07 May 2015, ZhouYuan wrote:
> >
> > >Hi,
> > >I have met many problems when I try to use the clause of "when".
> > >
On Thu, 07 May 2015, ZhouYuan wrote:
your second question regardin if/else was not yet addressed - so here are
some notes on trying to solve this - again this might not be the right
approach - only got it to work by removing the if structure isomorphisms !
>
>Also, another example can be w
On Sat, 09 May 2015, Nicholas Mc Guire wrote:
> On Thu, 07 May 2015, ZhouYuan wrote:
>
> your second question regardin if/else was not yet addressed - so here are
> some notes on trying to solve this - again this might not be the right
> approach - only got it to work by
Hi !
Writing some simple checks for user-space sample code to check that a
read loop has some error checking in it - the read loop should look
something like this:
do {
len = read(fd, buff + off, BUFFSIZE);
if (len < 0 && len != -EAGAIN) {
On Sun, 17 May 2015, Julia Lawall wrote:
> do while is not supported. Sorry.
>
interesting - did this just not get done or
is there a theoretical issue with do while constructs ?
thx!
hofrat
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://system
y" so those
cases are treated as false positives as well and not reported.
Signed-off-by: Nicholas Mc Guire
---
The cases reported all look like they are actual API inconsistencies but
not reporting does not mean there is no bug with respect to jiffies. This
still can miss some values e.
On Thu, 28 May 2015, Julia Lawall wrote:
>
>
> On Wed, 27 May 2015, Nicholas Mc Guire wrote:
>
> > schedule_timeout_* takes a jiffies value as timeout - passing in a constant
> > makes the timeout HZ dependent which is wrong. Checking for contstants only
> > yield
rtest possible
delay" so those cases are treated as false positives as well and not
reported.
Link: https://systeme.lip6.fr/pipermail/cocci/2015-May/002085.html
Signed-off-by: Nicholas Mc Guire
---
Note sure if a value of 2 should also be droped as false-positive
it seems to be in use in quite a
On Sun, 14 Jun 2015, Julia Lawall wrote:
> > +@script:python depends on report@
> > +p << cc.p;
> > +timeout << cc.C;
> > +@@
> > +
> > +if str.isdigit(timeout):
> > + if (int(timeout) != 1):
> > + msg = "WARNING: timeout (%s) seems HZ dependent" % (timeout)
> > + coccilib.report.print
On Thu, 18 Jun 2015, Julia Lawall wrote:
> Main changes:
>
> * There is a --use-gitgrep option for using git grep to preselect files.
> I'm not sure about the exact performance tradeoffs.
>
> * Small improvement on the handling of "default:" in a switch.
>
> * A change in the treatment of ... i
On Thu, 06 Aug 2015, Andrzej Hajda wrote:
> This patch fixes three things, listed in order of importance.
> 1. Removes matching of kmemdup from !patch rule - it is incorrect and
> in fact makes report mode unusable.
> 2. Adds unlikely to if clause. It allows to match more cases - the ones with
> u
On Thu, Dec 10, 2015 at 11:13:38AM -0500, Mike Marciniszyn wrote:
> From: Easwar Hariharan
>
> A code inspection pointed out that kmalloc_array may return NULL and
> memset doesn't check the input pointer for NULL, resulting in a possible
> NULL dereference. This patch fixes this.
>
> Reviewed-b
On Fri, Dec 18, 2015 at 07:33:36AM +0100, Julia Lawall wrote:
>
>
> On Mon, 14 Dec 2015, Nicholas Mc Guire wrote:
>
> > On Thu, Dec 10, 2015 at 11:13:38AM -0500, Mike Marciniszyn wrote:
> > > From: Easwar Hariharan
> > >
> > > A code inspection p
effectively no
difference with respect to the generated code (atleast not for the x86
.lst files of a few cases checked) but for cases where the timeout is
non-constant there is an actual call to jiffies_to_msecs() at runtime,
that overhead can be removed.
Signed-off-by: Nicholas Mc Guire
constants only yields many false positives so they are
filtered for digits only. A numeric value of 1 is though commonly in use
for "shortest possible delay" so those cases are treated as false
positives as well and not reported.
Signed-off-by: Nicholas Mc Guire
---
V2: fixed up the doc
Hi !
--no-loops is documented as:
--no-loops
drop all back edges derived from looping constructs - unsafe
the background is that some scanners will simply not make any
progress (e.g. linux-next/lib/rbtree.c:__rb_insert() is a perfect
"hang" without --no-loops for even
On Sun, Apr 03, 2016 at 07:30:16AM +0200, Julia Lawall wrote:
>
>
> On Sun, 3 Apr 2016, Diego Nieto Cid wrote:
>
> > Hello,
> >
> > I'm new to Coccinelle and there's a patch I wrote that doesn't
> > work as I expected.
> >
> > The purpose of the patch is to implement a toy stack smashing
> > p
Issue a warning if the if and else branch are identical - this can deliver
false positives as such constructs are sometime legitimate. In such cases
they should be documented so detecting false positives should be trivial
and if not it is a doc bug.
Signed-off-by: Nicholas Mc Guire
On Fri, Jul 22, 2016 at 06:56:47PM +0200, Julia Lawall wrote:
> > +virtual context
> > +virtual org
> > +virtual report
> > +
> > +@cond@
> > +statement S1;
> > +position p;
> > +@@
> > +
> > +<+...
> > +* if@p (...) S1 else S1
> > +...+>
>
> You don't need the <+... ...+>. Just put the if by its
constants only yields many false positives so they are
filtered for digits only. A numeric value of 1 is though commonly in use
for "shortest possible delay" so those cases are treated as false
positives as well and not reported.
Signed-off-by: Nicholas Mc Guire
---
V2: fixed up the documen
Report code constructs where the if and else branch are functionally
identical. In cases where this is intended it really should be
documented - most reported cases probably are bugs.
Signed-off-by: Nicholas Mc Guire
---
Tested with spatch version 1.0.5
As of 4.8.0 this reports about 90 cases
Hi !
On LKML Philippe Reynes posted an API update for ethtools API for
the pcnet32 care, basically to replace deprecated {get|set}_settings
by the new API calls {get|set}_link_ksettings.
see: http://lkml.org/lkml/2016/11/6/2
So the scanner for this is simple:
@find exists@
identifier oldapi,c
On Mon, Nov 07, 2016 at 01:14:12PM +0100, Julia Lawall wrote:
>
>
> On Mon, 7 Nov 2016, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > On LKML Philippe Reynes posted an API update for ethtools API for
> > the pcnet32 care, basically to replace deprec
usleep_range() min==max makes little sense at last for non-RT, so issue
a warning if delta is 0.
Signed-off-by: Nicholas Mc Guire
---
As of 4.9.0 this finds about 20 cases - all of which look like the
should be passing a range.
Patch is against 4.9.0 (localversion-next is next-20161213
On Tue, Dec 13, 2016 at 01:09:38PM +0100, Julia Lawall wrote:
>
>
> On Tue, 13 Dec 2016, Nicholas Mc Guire wrote:
>
> > usleep_range() min==max makes little sense at last for non-RT, so issue
> > a warning if delta is 0.
> >
> > Signed-off-by: Nicholas Mc Gui
Documentation/timers/timers-howto.txt outlines the intended usage of
usleep_range(), this spatch tries to locate missuse/out-of-spec cases.
Signed-off-by: Nicholas Mc Guire
---
V2: added context mode as suggested by Julia Lawall
added min
added in the range checks as they are resonably
On Thu, Dec 15, 2016 at 06:52:28AM +0100, Julia Lawall wrote:
>
>
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>
> > Documentation/timers/timers-howto.txt outlines the intended usage of
> > usleep_range(), this spatch tries to locate missuse/out-of-spec cases.
> &g
Hi !
Trying to do some verification of the coccinelle tool
it self and one of the tasks was to estimate false
negatives (so reliability not accuracy). To be able
to do that the first task was to determin if a semantic
patch specification would actually be looking at all
instances. The foll
On Tue, Aug 14, 2018 at 07:47:05AM +0200, Julia Lawall wrote:
>
>
> On Tue, 14 Aug 2018, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > Trying to do some verification of the coccinelle tool
> > it self and one of the tasks was to estimate false
&
t this only fits that specific pattern.
///
// Confidence: Low
// Copyright: (C) 2018 Nicholas Mc Guire, OSADL. GPLv2.
// Comments:
// Options: --no-includes --include-headers
virtual patch
virtual report
@badif@
position p;
statement S;
expression E1,E2;
@@
if@p (E1,E2) S
@script:python depends on re
HI !
Noticed that the nuveau driver uses a fair number of if
(var=val,boolean-condition){}
which while legal C-code just makes it hard to read - and some seems buggy
actually. The below spatch find about 50 cases - not sure though if this is
actually complete ?
thx!
hofrat
/// Check for
Hi !
I'm trying to detect false positive sparse messages by taking
the pattern and scanning with coccinelle for it so that the
fix could be generated. Basically the identification seems
to be working (a type-check on var is stil missing - but thats
a different issue) - the problem though is
On Mon, Apr 29, 2019 at 12:26:49PM -0400, Julia Lawall wrote:
>
>
> On Mon, 29 Apr 2019, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > I'm trying to detect false positive sparse messages by taking
> > the pattern and scanning with coccinelle
66 matches
Mail list logo
