Pippijn van Steenhoven wrote:
On Sat, Aug 15, 2009 at 06:04:39PM -0400, Joshua Cranmer wrote:
This is the part that I am most wary about. Elsa can output the AST into
an XML string, which can easily be read in by nearly every major
scripting language.
That is a valid point and I have thought about it. Not very much, but
when I first did this (yes, I already did all of this, but I lost it
during a hdd crash (I did it in 5 days time and was done before my weekly
backup)), I just removed everything that was not strictly necessary for
the parser to work. I was planning to re-add it as an external library
not included with the actual parser. Intrusive support is in fact against
that idea, so I was also thinking about just writing a visitor building a
perl data structure. That would probably be cleaner, too. On a whole, I
think moving stuff out of the actual ast into visitors is a good idea
(including the deparser, which is currently intrusive).
I would certainly agree with you that the XML stuff should be in a
visitor; the deparser (I presume that's the bpprint.ast and cc_print.ast
stuff?) could probably go as well. In terms of the .ast stuff, I think
that everything except cc.ast, gnu.ast, kandr.ast, and possibly
cc_elaborate.ast and cc_tcheck.ast could stand to be moved to visitors.
In my opinion, there is no reason to use the autotools suite if the
configuration arguments are simple enough: it adds complexity for so
little value (IMO).
I have been using (gnu) make for a long time now and I feel comfortable
with autotools. The makefiles would definitely become much shorter (I
have already done this before the hdd crash, as well :\) and in my
opinion, more understandable. It's basically just 6 lines of configure.ac
and 10 lines of makefile in addition to the source file lists.
For many people who work on Mozilla, the most that is used of autotools
is just a configure.in and the *.in files. I don't think too many people
would be remiss if you limited the usage to that amount of stuff.
Mostly, I just use gnu make,
though, which does all of that very well (gnu make is brilliant, it's a
freaking *programming* language).
I have no problems with GNU make, it's the automake that baffles me. I
already have a makefile somewhere that automatically compiles all files
in a tool directory into various programs without having to change it.
Two things to note here. When I last spoke with Taras, one of the things
he mentioned was that his biggest perceived barrier to removing
sm::string was concerns over the performance of the codebase. The goal
of porky is to be able to handle thousands of files of code, with header
includes that can easily push files past the 100,000 line mark or more.
It would be advisable to ensure that your removal does not adversely
impact performance of code parsing.
I highly doubt that replacing sm::string with std::string would adversely
impact performance, especially of code parsing, since code parsing does
not in fact operate on sm::strings very much. Anyhow, my tests before the
hdd crash much more proved the other way: it was faster. That said, I
didn't test it on very large code files, I mostly just #included every
C++ header and instantiated some of the std templates.
A good test would probably be some of Mozilla's large code files.
The other thing to note is the usage of boost::. I think there are
likely to be systems without boost (std::tr1 should be usable with the
appropriate g++ options); it may be inadvisable to require external
libraries if there is no real need for them.
TR1 has no intrusive_ptr, which would replace the refcounted pointer
class used in elkhound. TR1 has no ptr containers that would replace the
Obj containers of smbase. Boost has a very permissive licence, that would
allow you to ship the required headers with porky. There is no real need
for it, but it would remove a code module from maintainance. I am
generally very much in favour of removing as much from my own
maintainance as possible, so I can concentrate on what is really my goal.
I'm not at liberty to say whether or not boost should be required for
elsa; I was just pointing out that it might not be accepted by the
maintainer of the fork here. At the very least, leave that part for
after the other removals of smbase.
Macro support in terms of.. /*!foo/*/ /*<foo/>*/.. I mean.. what the heck
is this for? Does anybody even use that? Does it work at all? I haven't
tried very hard, since I was too annoyed by the apparently senseless
addition to the code that even uses an entire source file
(cppundolog.cc). That is what I want to remove. I can't currently think
of any other useless parts. It may be the only one, but I don't know what
it's for. Maybe SM can tell us something about it...
This is to be able to work with stuff in the middle of macros. Yes, it
is VERY much used by Mozilla (which is rife with macros for the core
APIs, which is what we are especially interested in tackling). Indeed,
this file was added after forking the original elsa code.
Adding perl support would be a good thing, I think. Transforming the
XMLised AST into perl datastructures would be more work and less
maintainable than having a visitor produce the structures. Someone did
the same for ocaml, I believe, I just can't think of who it was or what
he did it for.
I think it was the original author of elsa, who was apparently not
terribly happy about all the C++ stuff he was using (hence the extreme
nonusage of std::).
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
