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.
> 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
-include_headers should change the name then to --process-headers or
something along those lines.
> 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.
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 ...]
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.
thanks
bye
michael
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
