MIDLC: The MIDL Compatible IDL Compiler

Michael B Allen mba2000 at ioplex.com
Thu Dec 30 07:12:45 GMT 2004


On Thu, 30 Dec 2004 15:35:32 +1100
tridge at samba.org wrote:

> 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).

Yes. The entire src and dst buffers would need to be available.

>  > 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?

Src is just the raw NDR request buffer and dst is the NDR response
buffer. Other than that all you really need to know is that
Operation(...) will be called. But again this is just the current
call-glue that I think we've determined is NOT going to be used.

If you really want to understand more about how structures with pointers,
and arrays with pointers, and embedded conformant arrays and all that
jazz are actually handled look at how 'unsigned char **deferred' is used
in lsarpc_s.c I attached to a previous mail. The end result is actually
pretty simple (but it definately wasn't simple figuring it out -- it
took a couple of weeks of scrutinizing hexdumps of hacked MIDL stubs
and three complete emitter rewrites).

> 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.

Right.

> I'm guessing that dlim
> points at dst + sizeof(structure), and only limits the top level
> structure, not any pointer contents. Is that right?

No. The src is the *entire* raw NDR data for the call.  The slim and
dlim limit sentinel pointers are strictly for protection. Specifically
as the src pointer is advanced at any point it can be checked with a
trival expression:

  if (src < slim) /* good */
  if (src >= slim) /* bad */

If it turns out you really need an iterative solution then we can
fill/write out from/to a buffer in the ndr context as necessary. But
I'll cross that bridge when I get to it.

>  > 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.

Well in this particular case we can just make allocation failure a bailout
point. Or we can check return values and use macros to reduce clutter.

> I'd also prefer to avoid
> setjmp/longjmp if possible due to possible portability issues.

Oh, ok. I didn't know they weren't portable.

>  > 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.

I don't see that directory. I guess that's where the generated stuff
ends up? I'll have to figure out how to get subversion going. I think
I tried and failed once already. I have RH 7.3 which is apparently a
little old for some things. It's become a real pain.

Mike

-- 
Greedo shoots first? Not in my Star Wars.


More information about the samba-technical mailing list