Re: Looking for C declaration parser

agesen@Xenon.Stanford.EDU (Ole Agesen)
Mon, 6 Feb 1995 17:29:54 GMT

          From comp.compilers

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)
| List of all articles for this month |
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
--


Post a followup to this message

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