|Reusing free parsers for modern C++ email@example.com (Brian Smith) (2000-05-08)|
|Re: Reusing free parsers for modern C++ firstname.lastname@example.org (Bruce Stephens) (2000-05-10)|
|Re: Reusing free parsers for modern C++ email@example.com (Mark Brown) (2000-05-12)|
|Re: Reusing free parsers for modern C++ firstname.lastname@example.org (2000-05-15)|
|Re: Reusing free parsers for modern C++ email@example.com (Robert Sherry) (2000-05-22)|
|Re: Reusing free parsers for modern C++ firstname.lastname@example.org (Ira D. Baxter) (2000-05-24)|
|From:||Robert Sherry <email@example.com>|
|Date:||22 May 2000 23:10:30 -0400|
I while back I was involved with the Y2K problem. We were doing
evaluation of code for potential Y2K problems for a fee. At that time,
we had a tool which found potential problems by the spelling of
variable names. As a result we had a lot of false hits which had to be
edited out manually.
I developed a tool which eliminated most of these false hits
automatically. It did this by looking at the type of the
variable. This tool was based upon John Lilley's parser. I found the
parser to be well written, but not entirely bug free.
I think PCCTS is a fantastic set of tools, and I would highly
recommend it. Source code for PCCTS is available on internet.
It took me about 3 weeks to get to the point where I was ready
to start modifying the parser. By background included parsing and C++
but no experience with PCCTS.
I had a problem with the preprocessor. For statements like:
int flag = 1;
int flag = 0;
I needed to process both sides of the #ifdef. As a result the parser
would come up the variable flag being multiply defined. I found, that
when the parser had to many of these types of errors it would die with
a code dump or bomb box. I think you may have the same
problem. Perhaps my idea of processing both sides of the #ifdef is
wrong, but at that time my management felt it should be done that way.
I while back, I tried to port GCC to a DSP chip. I found that the GCC
code was quite difficult to read and there was no easy way to break
out the pieces that I needed. As a result I decided to use LCC
instead. LCC is a public domain C compiler available with source code
on the internet. The code is written in a clear fashion and it can
easily be adapted to others tasks. However, it does not support C++.
Brian Smith wrote:
> I am looking for comments and suggestions from people that have used
> the C++ front end of GCC or any other C++ parser for source code
> analysis. ...
Return to the
Search the comp.compilers archives again.