On Tue, 23 Jun 2015, Daniel Richard G. wrote:
> Hello Julia, > > On Tue, 2015 Jun 23 14:46+0200, Julia Lawall wrote: > > > > > > Bug 1: The patch adds a new "ctx" argument to calls to foo() and > > > qux(). If qux() is in the argument list of a call to foo(), however, > > > then the foo() call is not modified. > > > > Coccinelle picks one branch of the disjunction for matching against > > each "statement" (loop header, etc). It also tried to enforce the > > prioritization of things early in a disjunction over things later. > > This means that in your example it can't match both something with > > arguments and something without. > > > > On the other hand, the following works fine: > > > > @expression@ > > identifier F =~ "^(bar|qux)$"; > > @@ > > F( > > +ctx, > > ...) > > Ohh, so Coccinelle knows to drop the comma if the matched function has > no arguments. That is helpful! > > But I see that the original semantic patch will do > > - x += bar(1, 0) + qux(); > + x += bar(ctx, 1, 0) + qux(ctx); > > The argument is added to qux() as before, but bar() now gets it too, > within the same expression/statement. I'm not understanding the "one > branch" limitation in view of this... OK, perhaps I was not quite correct. Overall, it seems to be related to the goal of matching disjunctions on expressions from left to right. For example, if you have a pattern like: ( - &x + y | - x + z ) and the code you have is &x, then you expect to get y. Maybe it is throwing away matches with later terms that overlap with matches for earlier ones. I would have thought that only smaller matches would get thrown away, but whenever things overlap there is a danger of inconsistent modifications, so maybe any overlap at all is the better strategy. > > > Bug 4: Coccinelle can't handle an expression whose content is > > > affected by a cpp conditional. (In my scenario, I would like it to > > > ignore the WIN32 side.) Can this be addressed with an appropriate > > > macro-file definition? > > > > The problem is that the #ifdef is being ignored. It sees x += > > _timezone timezone / 3600; Unless you know the names of all the > > variables you want to ignore, I don't see an easy solution. > > Coccinelle already does some preprocessor handling; there isn't a way to > tell it to look at only one side of a particular conditional? The > example I gave is a trivial one---the expression could be written out > twice---but there are others less amenable to such a rewrite. There are some special cases where it ignores one side, but in general it doesn't. I think that to make this decision in general you have to parse, and the ifdefs block parsing. > > > There were also a couple of issues that appeared to be parse errors, > > > but were actually due to Coccinelle not recognizing C99 integer > > > types (e.g. "int32_t"). Would these not be reasonable to add to the > > > program's default initializations? > > > > Just add #define int32_t int to standard.h. > > Right; I used --macro-file so not to depend on site-specific changes. > But aren't these types ubiquitous enough (if not in the Linux kernel > tree) that they would merit inclusion in the upstream standard.h? With > all the other definitions in that file, it would seem a bit odd to leave > out something as basic as this. > > (Is there any advantage in writing "typedef int int32_t;" rather than > a #define?) Mostly Coccinelle has heuristics for identifying types. I'll have to check again why they were not triggered in your case. julia > > Sorry not to have responded sooner. Messages from nonmembers are > > moderated, and since most such messages are spam, I don't pay a lot of > > attention to them... > > I suspected as much; thank you for pulling this needle from the haystack > :] > > > --Daniel > > > -- > Daniel Richard G. || [email protected] > My ASCII-art .sig got a bad case of Times New Roman. > _______________________________________________ Cocci mailing list [email protected] https://systeme.lip6.fr/mailman/listinfo/cocci
