MIDLC: The MIDL Compatible IDL Compiler

[tridge at samba.org]

Mike,

 > What do you mean by range checking? The lim sentinel pointers are passed
 > all the way down into the {enc,dec}_ndr_* primative functions (and
 > *everything* is ultimately encoded using those) so there should be no
 > overruns.

oh! so, you pre-allocate the destination and pass a fixed limit
pointer? How does that work with potentially very large buffers? (many
mega-bytes is quite possible).

 > Oh, I thought the following qualified as "generic":
 > 
 > typedef int (*iface_Operation)(void *context,
 >            const unsigned char *src,
 >            const unsigned char *slim,
 >            unsigned char *dst,
 >            unsigned char *dlim)

I don't understand that bit ...

If this is a marshalling function, how does a single pointer and
pointer limit encode a complex structure that itself contains
pointers? Or does 'src' get cast to the right type of structure? If it
does, then what is slim for?

ahh, I think I see what you're doing. This is the server side stub
wrapper, and src is the raw NDR data, slim is the end of the data, dst
is a destination buffer to put the reply. I'm guessing that dlim
points at dst + sizeof(structure), and only limits the top level
structure, not any pointer contents. Is that right?

 > Actually I was thinking about this and instead of checking return values
 > for every single little primative call I think it would be smoother to
 > just set an error code in the 'ndr' context that triggers all functions to
 > just quit and not advance dst at all. So the functions are called but
 > nothing get's encoded. And I can maybe use setjmp/longjmp too. Don't
 > worry. The marshalling routines will be safe.

you need to be very careful with this. For example, if an array
allocation fails on unmarshall, then you need to bail out completely,
as you can't then walk the array. I'd also prefer to avoid
setjmp/longjmp if possible due to possible portability issues.

 > This model is pretty flexible. You could write a function to generate
 > interface documentation, ethereal dissector code, XML ... whatever. It's
 > the emit_{decoder,encoder}_fragment fucntions that do the real work.

yep, in many ways this parse/emit split is similar to pidl. It's
definately the right model, but it does get hairy in places.

 > Well it's not crystal what you want so I'll just get as far as I can with
 > the call-glue I have now knowing that we're just going to add a -t samba
 > option and insert samba specific call-glue later. Again I can make it
 > match the interface you have now (whatever that is). Try and think of a
 > good place to splice in MIDLC stubs and let me know.

the obvious place to start is to try and replace
librpc/gen_ndr/ndr_echo.[ch] with MIDLC generated code, leaving the
rest alone. If you can do that, then that gives a starting point for
experimentation.

btw, I'm not promising we will definately replace PIDL with MIDLC for
Samba4, but I will certainly look at it seriously if it can match
features (if only because I'd love someone else to be the primary IDL
compiler maintainer!)

Cheers, Tridge