On Thu, 4 Aug 2011, Michael Stefaniuc wrote:

> On 08/04/2011 11:17 AM, Julia Lawall wrote:
> > We were considering making some changes in the interaction with Coccinelle 
> > that would break backward compatability:
> > 
> > 1. Currently regular expression matching is indicated by ~=.  Perl uses =~ 
> > so we were considering to use that instead.  It might make it more clear 
> > that the regular expression matches a substring rather than the whole 
> > identifier.
> Hmm... could that be used to transition to PCRE based regexp without
> breaking backwards compatibility? With a depreciation warning for '~='
> and OCaml(STR) syntax. Keeping both forever without a warning would not
> be good as swapping ~= is very easy to do but very hard to spot.

We talked about that, but it seems like it could be very confusing for 
someone who doesn't know perl.

> > 2. Currently the options have the form, eg, -no_includes.  We could change 
> > them to eg --no-includes.
> +1
> 
> But what would be the opposite? Something like this would be nice:
> --includes=all       (-all_includes)
> --includes=local     (-local_includes)
> --includes=recursive (-recursive_includes)
> --includes=none as a synonym for --no-includes

So we can keep --no-includes?  I use it around 90% of the time, and 
--includes=none looks like a lot of typing...

> -include_headers should change the name then to --process-headers or
> something along those lines.

OK.

> > 3. The comment was made that the two names cocci(nelle) and spatch are 
> > confusing.  Should we more consistently use one or the other?  Which?  
> > (Personally I prefer cocci(nelle), because it is more consistent with the 
> > documentation and publications, and because I don't think spatch is 
> > unique.)
> cocci or coccinelle would be great!
> 
> > 4.  Are there any options that should have new names?
> -smpl_file is kinda long for an option that is always needed for the
> main coccinelle use mode. Having a short form for it would be nice.

Actually, above you suggested using cocci, so it would be --cocci-file 
(even longer).

> But what about going crazy and adding some DWIM to coccinelle when no
> command options are given?
> cocci <foo.cocci> <bar.c> [baz.c ...]
>   instead of spatch -smpl_file <foo.cocci> <bar.c> [baz.c ...]

One of the original developers was really opposed to this.

> cocci <foo.cocci>
>   instead of spatch -parse_cocci <foo.cocci>
> 
> cocci <bar.c> [baz.c ...]
>   instead of spatch -parse_c <bar.c> [baz.c ...]
> 
> Of course non-command options should not change the above behavior, e.g.:
> cocci --macro-file <macros> <bar.c>
> should still do a --parse-c
> 
> > 5.  Anything else that would involve removing something?
> The handling of macro/iso files to extend by default the builtin ones
> instead of replacing them. Or at least make it possible to do that.

For iso files, you should really use "using" in the semantic patch.  I 
only use -iso_file for getting rid of all isomorphisms, by using an empty 
file.

Thanks!

julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)

Reply via email to