On Mon, 22 Aug 2011, Simon wrote: > On Mon, Aug 22, 2011 at 10:44 AM, SF Markus Elfring < > [email protected]> wrote: > > > > I'd like to have a sort of C equivalent to this Perl module which > > > can do 'round trip' parsing of Perl source code into a structured, > > > hierarchical format, and back into Perl source code: > > > http://search.cpan.org/~adamk/PPI-1.215/lib/PPI.pm > > > > How do you think about the applicability of tools like the following for > > your > > use case? > > - OpenGrok > > - cscope > > - LXR Cross Referencer > > > > I have looked at those tools and dismissed them because the info they > provide does not appear detailed enough to e.g. exactly re-create the C > source file in question; so called round trip parsing. And some of them like > OpenGrok are quite heavy weight in terms of what you need installed to make > it do its regular job. The only two possibilities that I have come up with > so far are Coccinelle and maybe clang (but I'm no sure yet how to make it > give up its C tree with or without compiling fully). > > More about what I want to achieve: Whereas a tool like Coccinelle allows > humans to come up with patches to make changes to source files, I would like > software to be able to patch C sources on the fly. For example, I might have > a set of C source files which compile and run perfectly fine. My build > system might allow me to create a release build and a debug build. I could > permanently instrument the C source with macros which only get compiled into > the debug build (this is a great technique which I use today but the only > main downside is that it makes the source code more voluminous because of > all the instrumentation). What if the instrumentation could be added > on-the-fly? I.e. the build system generates a new foo.c file just for the > debug build. In this case I would get the best of both worlds; slim looking > source files and 'permanent' (now in the sense that it can be automatically > regenerated) debug instrumentation. In order to automatically add the debug > instrumentation to the debug foo.c file then my script needs to know all > about the original foo.c file. It's also important that the extra > instrumentation added does not change the line numbering otherwise it will > be difficult for me to match either compiler errors or run-time assert line > numbers with the original foo.c file which is the only file that I would be > editing for development. Does this make any more sense now?
What I proposed with adding comments will change the line numbers. I guess one could use /* */ comments. But it will still change the column numbers... But why not let Coccinelle do the instrumentation for you? julia _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
