Re: Reusing free parsers for modern C++

Robert Sherry <>
22 May 2000 23:10:30 -0400

          From comp.compilers

Related articles
Reusing free parsers for modern C++ (Brian Smith) (2000-05-08)
Re: Reusing free parsers for modern C++ (Bruce Stephens) (2000-05-10)
Re: Reusing free parsers for modern C++ (Mark Brown) (2000-05-12)
Re: Reusing free parsers for modern C++ (2000-05-15)
Re: Reusing free parsers for modern C++ (Robert Sherry) (2000-05-22)
Re: Reusing free parsers for modern C++ (Ira D. Baxter) (2000-05-24)
| List of all articles for this month |

From: Robert Sherry <>
Newsgroups: comp.compilers
Date: 22 May 2000 23:10:30 -0400
Organization: @Home Network
References: 00-05-034
Keywords: tools, PCCTS

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:

#ifdef DEBUG
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++.

                                                                Robert Sherry

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. ...

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.