On Thu, 4 Aug 2011, Michael Stefaniuc wrote: > 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.
No, sorry, that's not what I meant at all. I thought that having ~= and =~ would be very confusing for someone who doesn't know perl. They are just like each other, and one wouldn't know which is which. We have added PCRE regexpe and will add a flag eg --ocaml-regexps to allow one to use the OCaml ones. > >>> 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. OK. > >> -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. OK. That looks a lot like the C language though. > >> 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. OK, personally I don't have any problem with 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 I'm not sure about this. There are other options that only take a C file: parse_c, type_c, control_flow. > >>> 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. It's a good point that the macro files need to be better handled. Maybe we should have an environment variable for that? If someone mostly always works on one project, then they would always use the same macro definitions. We could also in general try to reduce the set of provided macro definitions. I think a lot of them are not necessary, and only cause some tokens to be unnecessarily skipped over. julia _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
