Re: C structure analyzer ("Reflection" in C?)

Keith Thompson <>
23 Jul 1999 22:16:42 -0400

          From comp.compilers

Related articles
C structure analyzer ("Reflection" in C?) (1999-07-19)
Re: C structure analyzer ("Reflection" in C?) (Jan Gray) (1999-07-20)
Re: C structure analyzer ("Reflection" in C?) (1999-07-21)
Re: C structure analyzer ("Reflection" in C?) (Keith Thompson) (1999-07-23)
Re: C structure analyzer ("Reflection" in C?) (Jerry Pendergraft) (1999-07-28)
Re: C structure analyzer ("Reflection" in C?) (Norbert Berzen) (1999-07-30)
Re: C structure analyzer ("Reflection" in C?) (Keith Thompson) (1999-07-30)
Re: C structure analyzer ("Reflection" in C?) (Dibyendu Majumdar) (1999-07-30)
Re: C structure analyzer ("Reflection" in C?) (Volker Denneberg) (1999-07-30)
Re: C structure analyzer ("Reflection" in C?) (1999-08-01)
| List of all articles for this month |

From: Keith Thompson <>
Newsgroups: comp.compilers
Date: 23 Jul 1999 22:16:42 -0400
Organization: CTS Network Services
References: 99-07-063
Keywords: C, tools writes:
> Hi,
> I'm dealing with a 3rd party API (The Eurex exchange "Values" API)
> that uses a large number of C structures. The exchange supplies C
> header files that describe structures which define the format of the
> input and output messages. These header files provide structures that
> define the message format of blocks of bytes that are sent to, and
> received from, the exchange.
> Does anybody know of a tool that I could use that converts the C
> structure definitions into some other source file that has each data
> member name, byte offset, size etc so that I could make a program to
> dynamically compose these "structures"?

Once upon a time, I wrote such a tool. (No, sorry, it's not
available.) I used a modified version of third-party freeware C
parser to parse the headers and generate a symbol table. From the
symbol table, I generated tables of type and member names. From the
tables, I generated C sources (with *lots* of ugly macros) that I
compiled and executed to generate more tables. And so on. (No, there
weren't an infinite number of passes, it just seemed that way.)

Extracting information from compiler generated debug info wasn't an
option, since the tool had to work on several different platforms.

As far as parsing is concerned, typedefs can be nasty. You might
consider grabbing an existing compiler and deleting what you don't
need, rather than grabbing a parser and adding what you do need.
Bitfields are also, ahem, interesting, since you can't take a
bitfield's address or use the offsetof() macro.

If you don't need the process to be 100% automated, you can probably
save a lot of effort by writing a quick and dirty tool to extract type
and member names, cleaning up the output manually, and transforming
that into C code that prints the size of each type, and the size and
offset of each member. Take a look at the way your implementation
defines the offsetof macro in <stddef.h>. If you understand how it
works, you can probably figure this stuff out.

Keith Thompson (The_Other_Keith) <>
San Diego Supercomputer Center <*> <>

Post a followup to this message

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