On 08/04/2011 11:06 PM, Julia Lawall wrote:
> 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.
So coccinelle won't add PCRE regexps? Not really a problem as for the
limited scope the standard POSIX regexps are good enough. And there is
python there for the advanced stuff.
>>> 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...
Ah no, keep --no-includes too. I was just thinking to add "none" for
consistency when selecting how the includes should be treated.
>> -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).
True, so having something like -c for that 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 ...]
>
> One of the original developers was really opposed to this.
I shouldn't have used "instead" as I don't propose to remove the command
options. If the user forces something with command line options then
cocci should stop any assumption and do what told. E.g.
cocci --cocci-file bar.c foo.cocci
should spit out tons and tons of errors from misparsing bar.c as a SmPL
file :)
But in the case when no command is given cocci could figure out what
would be sensible to do; there isn't much ambiguity there.
>> 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.
Heh, I needed only the macro file; added the iso file only because I
assumed they would be similarly handled.
bye
michael
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
