On Sun, 21 Aug 2011, Simon wrote:
> On Sun, Aug 21, 2011 at 9:41 PM, Julia Lawall <[email protected]> wrote:
>
> > On Sun, 21 Aug 2011, Simon wrote:
> >
> > > Hi Julia,
> > >
> > > FYI this is what -token_c does for me:
> > >
> > > $ cat foo.c
> > > #include <stdio.h>
> > > int
> > > main(void)
> > > {
> > > printf("hello world!\n");
> > > }
> > > $ spatch -tokens_c foo.c
> >
> > It's -tokens_c, not -token_c :)
> >
> > This is an option for debugging the C parser, not something one normally
> > uses.
> >
>
> Sorry. Thanks. How to understand the output? Thanks, Simon
It is printing the tokens defined in the parser (parsing_c/parser_c.mly).
It is not obvious to know what the various tags mean - they are internal
ocaml information. Perhaps the number relates to the position at which
the token is declared. Some of the numbers represent position
information.
julia
> > julia
> >
> > > init_defs_builtins: /usr/local/share/coccinelle/standard.h
> > > Tag100 (("#include ", "<stdio.h>", (0), ((("#include <stdio.h>", 0, 1, 0,
> > > "foo.c")), (0), ((0, 0, 0, 0)))))
> > > Tag2 (((("\n", 18, 1, 18, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n", 19, 2, 0, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag50 (((("int", 20, 3, 0, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n", 23, 3, 3, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag8 (("main", ((("main", 24, 4, 0, "foo.c")), (0), ((0, 0, 0, 0)))))
> > > Tag11 (((("(", 28, 4, 4, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag56 (((("void", 29, 4, 5, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag12 ((((")", 33, 4, 9, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n", 34, 4, 10, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag13 (((("{", 35, 5, 0, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n ", 36, 5, 1, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag8 (("printf", ((("printf", 41, 6, 4, "foo.c")), (0), ((0, 0, 0, 0)))))
> > > Tag11 (((("(", 47, 6, 10, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag7 ((("hello world!\\n", 1), ((("\"hello world!\\n\"", 48, 6, 11,
> > > "foo.c")), (0), ((0, 0, 0, 0)))))
> > > Tag12 ((((")", 64, 6, 27, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag29 ((((";", 65, 6, 28, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n", 66, 6, 29, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag14 (((("}", 67, 7, 0, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag2 (((("\n", 68, 7, 1, "foo.c")), (0), ((0, 0, 0, 0))))
> > > Tag126 (((("", 69, 7, 0, "foo.c")), (0), ((0, 0, 0, 0))))
> > >
> > > --
> > > Simon
> > >
> > > On Sat, Aug 20, 2011 at 10:11 PM, Julia Lawall <[email protected]> wrote:
> > >
> > > > On Sat, 20 Aug 2011, Simon wrote:
> > > >
> > > > > I followed the install.txt instructions and have been playing around
> > > > > with coccinelle-1.0.0-rc5 on Ubuntu 11.04 and have some questions:
> > > > >
> > > > > I'm interested in the idea of creating different builds of the same C
> > > > source
> > > > > file by instrumenting the source file on the fly. For example, I
> > might
> > > > have
> > > > > a release build of foo.c and a debug build of foo.c. The debug
> > version of
> > > > > foo.c might have access to reflective functions and data which are
> > only
> > > > > available in the debug version. My idea is to use coccinelle to
> > create
> > > > those
> > > > > functions and data on the fly. A simple example is as follows: Let's
> > say
> > > > > foo.c contains an enum. I'd like to auto-generate a reflective
> > function
> > > > > which given an enum, returns the enum as a string for
> > logging/debugging
> > > > > purposes. Of course, I could just write such an enum to string
> > function
> > > > > myself, but then every time I change the enum then I'd have to update
> > the
> > > > > enum to string function. How can I use coccinelle to give my scripts
> > the
> > > > > info about foo.c that they need in order to auto-generate such an
> > enum to
> > > > > string function? I have been playing around with -token_c and -type_c
> > > > which
> > > > > look promising. Is this the right way to go for what I want to do?
> > How
> > > > can I
> > > > > learn more about using -token_c and understanding the output?
> > > >
> > > > I'm not sure that -token_c or -type_c are what you want. Actually, I
> > > > don't know what -token_c is. When I try it, it tells me that it is an
> > > > unknown option. -type_c just pretty prints the source code with the
> > type
> > > > information.
> > > >
> > > > In general, what you want to do would be rather awkward, because
> > > > Coccinelle does not really provide facilities for converting things to
> > > > strings. Also there is no way to match only enum declarations and get
> > the
> > > > complete information about the declaration, although that could be
> > fixed.
> > > >
> > > > If you wanted to know the fields in a structure, you could do the
> > > > following:
> > > >
> > > > @r@
> > > > identifier str;
> > > > field list fs;
> > > > @@
> > > >
> > > > struct str { fs } ;
> > > >
> > > > @script:ocaml s@
> > > > str << r.str;
> > > > fs << r.fs;
> > > > res;
> > > > @@
> > > >
> > > > res := Printf.sprintf "\"struct %s { %s };\\n\"" str fs
> > > >
> > > > @@
> > > > identifier s.res;
> > > > @@
> > > >
> > > > int main() {
> > > > ++ printf(res);
> > > > ...
> > > > }
> > > >
> > > > The middle rule converts the information to a string, which the third
> > rule
> > > > uses as an identifier, because only identifiers can be imported from a
> > > > scripting language to SmPL code. But this is a hack, because after the
> > > > transformation, the identifier will look like a string. You can use
> > > > python rather than ocaml, if you prefer. See demos/pythontococci.cocci
> > > > for an example.
> > > >
> > > > > Another thing that I've been thinking about is how coccinelle deals
> > with
> > > > > #include files. Where can I read up on its handling of included
> > header
> > > > > files?
> > > >
> > > > http://coccinelle.lip6.fr/docs/options.pdf, in the section about
> > include
> > > > files (page 6). There is a typo - really_all_includes should be
> > > > recursive_includes.
> > > >
> > > > The various options give various heuristics for finding include files.
> > > >
> > > > Include files are mostly useful for giving type information.
> > Coccinelle
> > > > tries to parse C code independent of macro definitions, so having the
> > > > macro definitions from the include files is not likely to improve
> > parsing.
> > > >
> > > > > Assuming there is a good answer to the first part of my question, in
> > an
> > > > > extreme example, how could I get coccinelle to tell me whether
> > INVISIBLE
> > > > is
> > > > > part of cardsuit or not for my particular build? Obviously my script
> > > > which
> > > > > wants to auto-generate the debug_cardsuit_enum_to_text() function
> > needs
> > > > to
> > > > > know whether DIAMONDS will be 1 or 2.
> > > > >
> > > > > enum cardsuit {
> > > > > CLUBS,
> > > > > #ifdef SECRETSUIT
> > > > > INVISIBLE,
> > > > > #endif
> > > > > DIAMONDS,
> > > > > HEARTS,
> > > > > SPADES
> > > > > };
> > > >
> > > > Coccinelle is not build-sensitive at all. It has no idea whether a
> > > > particular #ifdef constant is defined. You may want to look at
> > undertaker
> > > > (Lohmann et al). Their work is oriented towards configuration issues.
> > > >
> > > > julia
> > > >
> > >
> >
>
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
