MIDLC IDL Compiler

[Andrew Tridgell]

Michael,

I should explain a little more about how pidl handles element oriented
meta-data and multiple passes.

It's quite common in IDL for the generated code to need to be able to
remember something about a element deeply nested in the structures,
then come back later and use that bit of meta information at a later
date (like in a subsequent pass). One situation where this is needed
is the size being declared after the array (like you mentioned), but
it also happens with "relative" marshalling of pointers (like in
spoolss and security.idl).

The relative pointers are particularly nasty as they cross structure
boundaries. So the 2nd pass doesn't happen till you have not only
completed this structure, but also completed all the upper level
encapsulating strucrures!

When I was first writing pidl this was a problem I hit my head against
for a long time, then I finally realised the general solution. The
trick is that the address of the element is a unique key that can be
used to lookup meta-data between passes.

Thats what the ndr_token_*() functions are about. It allows the code
generator to say something like "store this bit of meta-data with that
element in this structure I'm working on, and then give it back to me
when I want it later". The key is that it does this wihout polluting
the structure that is visible in the user API with little bits of
meta-data cruft (Samba3 used extra cruft in the structures).

I am thinking of extending the use of ndr_token_*() in pidl to use it
for more element properties later, allowing more code to be in the
generated ndr library and less in the structure specific generated
code. Unfortunately I didn't think of the ndr_token_*() idea until
after I had written most of pidl, so I only used it for two things
(relatives and structure size checking). If I had thought of it
earlier I could have made pidl much simpler!

Cheers, Tridge