Related articles |
---|
Looking for C declaration parser lehotsky@max.tiac.net (1995-02-06) |
Re: Looking for C declaration parser agesen@Xenon.Stanford.EDU (1995-02-06) |
Re: Looking for C declaration parser flisakow@cae.wisc.edu (1995-02-06) |
Re: Looking for C declaration parser vinall@VNET.IBM.COM (1995-02-07) |
Re: Looking for C declaration parser rankin@eql.caltech.edu (1995-02-07) |
Re: Looking for C declaration parser kik@ironwood.cray.com (1995-02-08) |
Re: Looking for C declaration parser probertm@ariz.library.ucsb.edu (1995-02-11) |
Re: Looking for C declaration parser jejones@microware.com (1995-02-13) |
Newsgroups: | comp.compilers |
From: | agesen@Xenon.Stanford.EDU (Ole Agesen) |
Keywords: | C, tools |
Organization: | Stanford University: Computer Science Department, CA USA |
References: | 95-02-067 |
Date: | Mon, 6 Feb 1995 17:29:54 GMT |
lehotsky@max.tiac.net (Alan Lehotsky) writes:
>I'm looking for a tool that parses C declarations and constructs a
>simple symbol table. I want to use this to parse simple .h files and
>generate equivalent data structures in other languages, such as PL/I.
...
>I suppose I could start with a complete C front-end, but that would be
>a lot of work to reduce to just a declaration parser.
Depending on how broad coverage of C decl's you want/need, starting with
a complete C parser may be the best choice in the end. For example,
nothing prevents a C programmer from putting full C functions in header
files -- a parser for a subset of C would have a hard time dealing with
this.
Another complication you may face is the preprocessor. Do you want to
preprocess the files first? If yes, declarations of the form
#define DUCK 45
disappear before the parser even sees the source!
Not to mention horrors like:
#define getc(p) (--(p)->_cnt>=0? ((int)*(p)->_ptr++):_filbuf(p))
#define putc(x, p) (--(p)->_cnt >= 0 ?\
(int)(*(p)->_ptr++ = (unsigned char)(x)) :\
(((p)->_flag & _IOLBF) && -(p)->_cnt < (p)->_bufsiz ?\
((*(p)->_ptr = (unsigned char)(x)) != '\n' ?\
(int)(*(p)->_ptr++) :\
_flsbuf(*(unsigned char *)(p)->_ptr, p)) :\
_flsbuf((unsigned char)(x), p)))
On the other hand, if you decide not to preprocess, you are no longer
"merely" parsing C. Now your parser will have to deal with all the
additional syntax that the preprocessor normally eliminates. Not only
that, it will probably have to interpret a lot of those structures.
Either way, it's not going to be easy, if you want full coverage. (As is
often the case with C).
[Which tool to use? Here's an option:
Mango is an object-oriented parser generator tool written in the Self
language. Both Mango and Self are available from ftp: self.stanford.edu.
Mango includes a grammar for ANSI C. Even if you don't want to use Mango,
this grammar may be a good starting point. It is closely based on the K&R
(ANSI version) grammer but documents and corrects some problems with that
grammar. You may also want to look a the Mango technical report (same ftp
address). It discusses some of the problems of parsing C (including the
infamous typedef ambiguity)].
Best of luck
Ole
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.