Parse data with C header files which defined the structures - c

Question

I have a C header file like this:
#define NAME_LEN 8
#define DEV_MAX 4
typedef struct __device
{
int iDevID;
int iDevSN;
}DEVICE;
typedef struct __person
{
int iID;
char acName[NAME_LEN];
DEVICE aDevices[DEV_MAX];
}PERSON;
and a binary data file maybe like this:
0000000 01 00 08 00 4a 61 63 6b 00 00 00 00 0a 00 00 00
0000020 11 11 11 11 0b 00 00 00 22 22 22 22 0c 00 00 00
0000040 33 33 33 33 0d 00 00 00 44 44 44 44
All that what I need is to visulized data representation with field names using the C header file above....
It'll be better like this...
m--iID : 0x80001
m--acName : Jack
m--aDevices[]
|--aDevices[0]
|--|--iDevID : 0xa
|--|--iDevSN : 0x11111111
|--aDevices[1]
|--|--iDevID : 0xb
|--|--iDevSN : 0x22222222
|--aDevices[2]
|--|--iDevID : 0xc
|--|--iDevSN : 0x33333333
|--aDevices[3]
|--|--iDevID : 0xd
|--|--iDevSN : 0x44444444
or other structured data .. xml / python pickle / json strings / whatever
Of course, the header file which I faced is far more complicated, there will be a msgtype and a msglenth field in the data, so I can find out which is the correct structure and how long is it.

Answer 1

How badly do you need that?
A possible solution might be to make a GCC plugin or a MELT extension (MELT is a domain specific language to extend GCC), but to do that you'll need to understand in some details the internal representation of GCC (notably Tree, and perhaps Gimple), and that will take you some time (days, not hours).
If your declarations are simpler, perhaps consider using SWIG (or maybe the RPCXDR parser), but that supposes that you are able to change or simplify them.

Answer 2

If the binary format were identical to the memory layout of your structure, you could just cast it, no parsing required (with some caveats). However, that evidently isn't what you mean, since your hex dump and sample output don't match that interpretation.
You'll need to actually explain your format though: as described below, it isn't obvious.
You seem to have fixed-length 4-octet integers in little-endian order, OK.
If I assume variable length strings with a nul-terminator, 4a 61 63 6b 00 = acName:"Jack" and 0a 00 00 00 = iDevID:0x0a looks ok, but there is a 3-octet sequence between them I don't know the meaning of.
Or is Jack not nul-terminated, in which case it's fixed at 4 characters long and not the 8 you defined for NAME_LEN? That would make 00 6f 70 65 another 4-byte integer, but I still don't know what it means.
...