[jcifs] NDR

Michael B Allen mba2000 at ioplex.com
Sun Sep 12 23:59:42 GMT 2004

I thought you needed to know the size of a stucture before you encode it
so you know where to encode what the deferred pointers point to. That's
not quite true. I was looking at the following use-case:

    typedef struct {
        [length_is(v + 0)] small m1[5];
        int *i;
        [length_is(v + 1)] small m2[5];
        [length_is(v + 2)] small m3[5];
        int v;
    } wacko_t;

There is no practical way to precompute the size of this structure without
knowing v but v cannot be located unless you decode the members that
preceed it. Catch-22. You must decode each member not by following
pointers as they are encountered (as idlc stubs do now) but keep going and
then decode what the pointers point to recursively at that end location.

I think this post-order recursion might be simpler than the in-order
business I'm doing now but of course idlc stubs are fundamentally wrong.
At least the emitter is wrong. I'll have to refactor it quite a bit. But I
think the result will be a little smaller, tighter, and easier to
understand. And most important they will be correct.

On a related note, I noticed another thing that surprised me a little (at
first). If you have a structure with an embedded (not a pointer)
conformant array (conformant means you have to compute the size of the
array at runtime) like:

    typedef struct {
        uint8_t revision;
        uint8_t sub_authority_count;
        uint8_t identifier_authority[6];
        [size_is(sub_authority_count)] uint32_t sub_authority[*];
    } sid_t;

the whole structure is actually prefixed with a 32bit integer indicating
the size of the array (in this case 'sub_authority_count'). In Samba IDL
they actually use a dom_sid2 structure that has a 'count' field prefixed.
I guess PIDL doesn't quite support embedded conformant arrays. This leads
one to wonder why sids in security descriptors do NOT have this prefixed
value. Clearly it is because they are not encoded as NDR. This actually
makes sense considering there are transact2 SMBs that set and get security
descriptors using the same format and they're complicated enough that they
understandibly decided to use transmit_as to reuse the same marshalling


More information about the jcifs mailing list