On Fri, 24 Sep 2010, Greg McGary wrote:
> Yes, the two-rule approach works--that's what I started with. The ioctl_ref
> rule
> is the anchor for a series of six follow-on rules that apply transformations
> to
> ioctl-func decls. If I have two rules, then I need to replicate the six
> follow-on
> rules with trivial modifications, one for each of unlocked_ioctl and
> compat_ioctl.
> The unified rule using (...|...) is highly desirable to avoid duplication for
> sake
> of development and maintenance.
Undoubtedly, it would be better to have disjunctions in this case as well.
Without that there is a slightly convoluted way that you can avoid
duplicating all of the rest of the rules:
@ ioctl_ref @
identifier fops_id;
identifier ioctl_id;
identifier I;
position p;
@@
struct file_operations fops_id = {
.I = ioctl...@p,
};
@
@ ui @
identifier ioctl_ref.fops_id;
position ioctl_ref.p;
@@
struct file_operations fops_id = {
.unlocked_ioctl = ioctl...@p,
};
@ ci @
identifier ioctl_ref.fops_id;
position ioctl_ref.p;
@@
struct file_operations fops_id = {
.compat_ioctl = ioctl...@p,
};
@depends on ui || ci@
position ioctl_ref.p;
@@
...
In the last rule, you can do what you like with the structure, and if you
put @p on ioctl_id then you will be touching one of the desired
initializations.
A weak point of this strategy, though is that you can't inherit position
variables over transformation rules. So you can only have one
transformation rule at the end.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
