dcerpc_winreg_QueryValue

[Michael B Allen]

On Thu, 9 Dec 2004 16:50:26 +1100
tridge at samba.org wrote:

> Jelmer,
> 
>  > | WERROR winreg_QueryValue(
>  > | 	[in,ref] policy_handle *handle,
>  > | 	[in] winreg_String valuename,
>  > | 	[in] uint32 *reserved,
>  > | 	[in] uint32 *offered,
>  > | 	[in] uint32 unknown1,
>  > | 	[in] uint32 unknown2,
>  > | 	[out] uint32 *type,
>  > | 	[out,size_is(*val_length),length_is(*val_length)] uint8 *data,
>  > | 	[in,out] uint32 *offered2,
>  > | 	[in,out] uint32 *val_length
>  > | );
> 
> I don't think this is quite right. I think the correct IDL is this:
> 
> 	WERROR winreg_QueryValue(
> 		[in,ref] policy_handle *handle,
> 		[in] winreg_String value_name,
> 		[in,out] uint32 *type,
> 		[in,out,size_is(*size),length_is(*length)] uint8 *data,
> 		[in,out] uint32 *size,
> 		[in,out] uint32 *length
> 	);
> 
> The problem is that pidl in its current form cannot handle size_is()
> and length_is() for variables that occur after the array in the
> structure. I've got a prototype of a fix for this, and will commit
> once I have it fully working (it gets quite complex).

Actually there's an interesting use-case that prompted me to completely
rewrite my midlc emitter early on. Consider this beauty:

    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;

Because MIDL successfully encodes this without using additional
conformance information (unlike an embedded conformant array that
prefixes the structure with it's size) the encoder MUST decode each
member in order before recurring to decode sub-objects (e.g. elements
of the array that contain pointers for instance) to get to v. In my
first version of the compiler I pre-computed the size of a structure
or array and set the deferred pointer to that location before decoding
each member. That technique was surprisingly successful but unfortunately
turned out to be totally wrong :-/

> I have tested QueryValue with a hacked up version of my prototype and
> it works fine. As it gets rid of all the unknown variables, and makes
> the IDL much simpler I suspect its right.
> 
> Note that "data" is an [in] variable in the new IDL. This is pointless
> of course, but it is common in Microsoft IDL, and explains the unknown
> fields.

That's it! That's definately right. I knew there was something weird
going on. I just didn't see it.

Mike

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