gmane.comp.version-control.coccinelle

Re: isomorphism with unlikely

Lars-Peter Clausen — 2013-05-20T19:13:34

But for some reason it does not. With --verbose-match I can see that it
generates the correct isomorphisms (both for the case that r is a pointer or
that r is an integer), but for some reason they don't seem to match.

The testcase is simple:

cocci file:

< at >< at >
expression *r;
statement S;
< at >< at >
*if(!r) S

c file:

int foo(struct resource *r)
{
if (r == NULL)
return 0;
return 1;
}

- Lars

Re: isomorphism with unlikely

Julia Lawall — 2013-05-20T18:51:55


It should work if r has pointer type.  Otherwise, if r is not a pointer, 
then !r should become r == 0.

julia

Re: isomorphism with unlikely

Lars-Peter Clausen — 2013-05-20T18:26:04

No, just unlikley(r == NULL) also matches !r (and unlikely(!r)). This should
also work for unlikely(!r) matching unlikely(r == NULL) but for some reason
it doesn't. I just did a quick test and it looks as if even 'if(!r) ..."
doesn't match 'if(r == NULL) ...' either.

- Lars

Re: isomorphism with unlikely

Wolfram Sang — 2013-05-20T18:24:18


Okay, but I would then still need 'unlikely(!r)' and 'unlikely(r ==
NULL)' because the !r isomorphisms won't apply. I'd like to have both :)


True, thanks! Slowly getting back to it...

Re: isomorphism with unlikely

Lars-Peter Clausen — 2013-05-20T17:47:20

There is already an isomorphism for unlikely. But it is in one direction
only, so 'unlikely(E)' in your cocci script will also match 'E', but 'E'
wont match 'unlikely(E)'.

So in your case the script could be reduced to:


Btw. if you use 'statement S;' and 'if(...) S' instead of '{ ... }' you'll
also be able to match if there is only a single statement without brackets
after the if.

- Lars

isomorphism with unlikely

Wolfram Sang — 2013-05-20T17:34:06

Hi,

using 1.0-rc16 from debian, I use the following semantic patch:

< at >< at >
expression r, p, n;
< at >< at >
r = platform_get_resource(p, IORESOURCE_MEM, n);
...
(
-if (!r) { ... }
|
-if (unlikely(!r)) { ... }
|
-if (unlikely(r == NULL)) { ... }
)

and running against the latest kernel tree (~3.10-rc1):

spatch --sp-file unlikely_iso.cocci ~/Kernel/linux/drivers/net/ethernet/renesas/sh_eth.c

gives me a match:

-if (unlikely(res == NULL)) {
...

Note that I have two alternations with 'unlikely' because using '!r'
alone will not give me a match. I guess the isomorphism is skipped for
some reason when used as an argument of unlikely. If so, is it possible
to enforce it somehow? Or would it be even better to make 'unlikely' an
isomorphism itself, so that the semantic patch doesn't need to know
anything about 'unlikely'?

Thanks,

   Wolfram

Re: 1.0.0-rc17: Further fine-tuning for the build system?

SF Markus Elfring — 2013-04-29T09:52:58


Which build system do you use for this software in Fedora?
http://pkgs.fedoraproject.org/cgit/coccinelle.git/

Regards,
Markus

Re: Coccinelle question

Julia Lawall — 2013-04-29T02:52:04


Specific points are that it follows the control-flow graph, via the ...
operator, it lets you match against metavariables that accumulate
properties from other matches, so you can make generic specifications, and
it is (mostly) aware of type information.


Only somewhat.  Within a given rule, links to where C variables are bound
are taken into account.  But when a metavariable is inherited from one
rule to the next, all of this information is dropped.  This is in part
because Coccinelle supports transformation as well as matching, and you
could transform the variable declaration itself.  For example, you could
decide that you don't like variables being declared in the branches of an
if statement, and move the declarations up to top level.  The same
variables are still attached to the same binder, but by the way Coccinelle
is constructed (added code is not really interpreted) it would be hard to
detect this.

This may seem like a bug, but in practice, at least on Linux code, it can
be more of a feature.  Li

Coccinelle question

Majid Java — 2013-04-24T10:03:35

Hello,

last night i saw your website and projects from google search im really
interested in what Coccinelle doing as i understand its kind of open source
c parser library that follow in source code for variables and trace all
source and headers for it,Right?

now i have some questions:
Are you take care of Variable Scopes when you are searching the source code?

Thanks

Re: junk output

Julia Lawall — 2013-04-26T14:45:57


Sorry about that.  I'm glad that the problem is already fixed :)

julia

Re: junk output

Artem Bityutskiy — 2013-04-26T14:04:20

Oh, many thanks Richard for looking at this so quickly and creating a
bug!

Re: junk output

Richard W.M. Jones — 2013-04-26T14:07:01

I don't know why it happens, but updating to -rc17 fixes it,
so I'll get an update in soon.

Rich.

junk output

Artem Bityutskiy — 2013-04-26T13:52:17

Hi Julia, Richard,

not sure if this was already reported, but the latest Fedora 18
coccinelle produces a lot of junk. Just an example using the linux
kernel scripts:

$ spatch -sp_file ./scripts/coccinelle/free/clk_put.cocci drivers/gpio/gpio-sch.c

init_defs_builtins: /usr/share/coccinelle/standard.h
HANDLING: drivers/gpio/gpio-sch.c
No matches found for clk_get clk_put
Skipping:drivers/gpio/gpio-sch.c
left
left
left
left
left
left
left
right
right
right
right
right
right
left
left
left
left
left
left
left
left
left
left

Notice these lefts and rights.

$ rpm -q coccinelle 
coccinelle-1.0.0-0.rc14.6.fc18.x86_64

Any suggestions?

Thanks!

Re: junk output

Richard W.M. Jones — 2013-04-26T13:57:30

[...]

I can confirm this happens.  I have filed a bug:

https://bugzilla.redhat.com/show_bug.cgi?id=957169

Rich.

Re: 1.0.0-rc16: Further fine-tuning for the build system?

SF Markus Elfring — 2013-04-26T11:28:31


That is a pity. But I thank you very much for this feedback.



It seems that it is hard to find more software developers and reviewers 
who dare to fiddle with the build setup here.

Regards,
Markus

Re: 1.0.0-rc16: Further fine-tuning for the build system?

Peter Senna Tschudin — 2013-04-26T11:03:15

Hello Markus,

I'm following this topic since your first message. I'm sure it is not
your intention, but to me, your tone is not friendly. You are adding
little and complaining a lot. I can see your frustration, but I have
the impression that you do not care about how people feel about your
E-mails. The problem is that when you want something and you are not
friendly, people will not want to help you. By the tone in your
E-mails, I do not want to help you.

The people involved, including Julia, are busy, and they know exactly
what the project goals are. So if something is going wrong with your
patches / requests, your first reaction should be always to understand
why it is going wrong. Your current approach will not get you very far
and you will not be happy with the results.

Coccinelle is a great project, and I can ensure you that all patches
that add to Coccinelle will be seriously considered to be applied.
This means that Julia and other people will consider the pros and cons
of the patch and decide if i

Re: 1.0.0-rc16: Further fine-tuning for the build system?

Julia Lawall — 2013-04-26T10:25:02


My point of view regarding the build system is that, on the one hand, at
the moment, I don't have any local resources with expertise in build
systems and on the other hand the build setup is extremely critical.
So I am not currently willing to make changes without an actual need from
a user.  An actual need would be a case where it is impossible to build
Coccinelle in any way on a given machine.  It is not a case where eg out
of tree builds don't work or parallel builds don't work.  In those cases,
one can easily avoid the problem by building in another way.

If several people want to work on and validate any solution that adds some
such inessential functionality, then I might consider integrating the
change.  But I don't have the expertise to evaluate such patches myself,
so I won't integrate such patches if they have only been tested by the
submitter.

This doesn't apply to ML patches.  I have received several patches adding
support for various strange C extensions, and I have no problem with
integrating

Re: 1.0.0-rc16: Further fine-tuning for the build system?

SF Markus Elfring — 2013-04-26T10:15:33


If Julia will show more willingness to handle patches for the build 
system, I am going also to invest more efforts into concrete fixes.



I do not want that, too. But other software developers might have got a 
higher reputation so that their update suggestions or source code review 
advices get easier accepted than change requests from me.

Regards,
Markus

Re: 1.0.0-rc16: Further fine-tuning for the build system?

Richard W.M. Jones — 2013-04-26T09:52:05

If you'd read what I linked to:

http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/

then you'd see how to proceed.  It's NOT by badgering Coccinelle
upstream and trying to get other people to argue your case for you.

Rich.

Re: 1.0.0-rc16: Further fine-tuning for the build system?

SF Markus Elfring — 2013-04-26T09:36:19


I will not provide long explanations and concrete patches if I get clear 
responses from the project leader that she does not want to decide on 
them so far.
When will any pull request become acceptable from an other Git repository?

Regards,
Markus

Re: 1.0.0-rc16: Further fine-tuning for the build system?

SF Markus Elfring — 2013-04-26T09:10:45


I am trying to find more software developers and packagers who know the 
Autotools good enough. I hope that corresponding updates can be reviewed 
in a constructive way then.



Are you used to conditions which should be considered for the topic 
"out-of-source builds / parallel build trees"?

I pointed out some open issues to make the build configuration 
consistent again.
https://systeme.lip6.fr/pipermail/cocci/2013-March/000220.html
http://article.gmane.org/gmane.comp.version-control.coccinelle/3054



I got responses from Julia that she is not in the mood for the 
integration of fixes for the current build setup so far.

Regards,
Markus