Re: parsing C function declarations to generate code to serialize the formal arguments

"Ira Baxter" <idbaxter@semdesigns.com>
24 Dec 2006 11:01:10 -0500

          From comp.compilers

Related articles
parsing C function declarations to generate code to serialize the form einatbg@zahav.net.il (Moshe Pfeffer) (2006-12-14)
Re: parsing C function declarations to generate code to serialize the eliotm@pacbell.net (Eliot Miranda) (2006-12-14)
Re: parsing C function declarations to generate code to serialize the DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-12-14)
Re: parsing C function declarations to generate code to serialize the alex_mcd@btopenworld.com (Alex McDonald) (2006-12-15)
Re: parsing C function declarations to generate code to serialize the idbaxter@semdesigns.com (Ira Baxter) (2006-12-24)
| List of all articles for this month |

From: "Ira Baxter" <idbaxter@semdesigns.com>
Newsgroups: comp.compilers
Date: 24 Dec 2006 11:01:10 -0500
Organization: NewsGuy - Unlimited Usenet $19.95
References: 06-12-056
Keywords: C, parse

"Moshe Pfeffer" <einatbg@zahav.net.il> wrote
> I am looking for an elegant method to do the following. Are there
> tools available to help? Have you done something like this that I may
> also try?
>
> I wish to take a C header file consisting of a list of function
> declarations, parse the function declaration to obtain a
> representation of the formal parameters from which to generate C
> code. Each argument must be processable as a tree, since it may be a
> struct, or pointer to a struct, with further structs/pointer to
> structs as it's members, or member's members, etc. ...


> Once the forest is represented, I then need to generate code for each
> cluster (i.e. each function).
>
> Thanks in advance,
> Moshe


> [Generally speaking, you can't parse a C header file with anything less
> than a full C parser. If you have particular applications in mind, you
> might be able to cheat and get by with less. -John]


Sounds like Moshe wants to serialize data for some source program he
likely doesn't control. That pretty much forces you into needing a
full parser, simply because you have to handle everything that can
occur in the input. What is worse is you need a full parser for the
specific dialect (it is very hard to find a parser that ignores
arbitrary dialect differences).


There *are* tools available to help.
The DMS Software Reengineering Toolkit has robust complete C parsers
for ANSI , GNU 2/3/4, and MS Visual dialects,
that produce ASTs, and do complete name and type resolution of
every symbol (e.g., produces a symbol table as well as enables
the determination of the type of any arbitray expression.).
DMS can provide pattern-driven transformations to enable one
to construct arbitrary derived C trees and then pretty print.


Moshe has a set of specific requirements. To the extent they are
will defined, DMS can likely carry them out.




See http://www.semanticdesigns.com/Products/FrontEnds/CFrontEnd.html




--
Ira Baxter, CTO
www.semanticdesigns.com


Post a followup to this message

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