On Thu, Oct 18, 2007 at 04:02:40PM +0100, Robert Shearman wrote: > Dan Hipschman wrote: > >@@ -1859,6 +1859,7 @@ static int get_struct_type(var_list_t *fields) > > case RPC_FC_OP: > > case RPC_FC_CARRAY: > > case RPC_FC_CVARRAY: > >+ case RPC_FC_BOGUS_ARRAY: > > has_pointer = 1; > > break; > > > >@@ -1897,15 +1898,9 @@ static int get_struct_type(var_list_t *fields) > > /* fallthru - treat it as complex */ > > > > /* as soon as we see one of these these members, it's bogus... */ > >- case RPC_FC_IP: > > case RPC_FC_ENCAPSULATED_UNION: > > case RPC_FC_NON_ENCAPSULATED_UNION: > >- case RPC_FC_TRANSMIT_AS: > >- case RPC_FC_REPRESENT_AS: > >- case RPC_FC_PAD: > >- case RPC_FC_EMBEDDED_COMPLEX: > > case RPC_FC_BOGUS_STRUCT: > >- case RPC_FC_BOGUS_ARRAY: > > return RPC_FC_BOGUS_STRUCT; > > } > > } > > > > Hi Dan, > > What's the reasoning behind this part of the patch? It seems to me like > most of the cases that you removed from becoming a complex structure are > actually valid. The hunk further up also confuses me - the presence of a > complex array shouldn't just make the resulting structure into a pointer > structure, it should make it into a complex structure, since it can't be > marshalled solely by using memcpy.
Hi. For the first hunk: Fields that are actually declared as arrays (with [] notation) are handled above, so if we get to that part of the code and find a bogus array, it must be a pointer with a size_is attribute. For conformant arrays (bogus included) that are declared as pointers, MIDL treats them like pointers to arrays, instead of just embedded arrays. Since the field is listed as a pointer, all we need is PSTRUCT (or variant thereof). If I understand the RPC engine correctly, a PSTRUCT should get memcpy'd initially, but then for each pointer it goes through and marshals whatever it points to separately and then updates the value. For the second hunk: I moved the bogus array type for the reasons mentioned above. The other things there aren't real types. Pointers to FC_IP are handled above, and it should be impossible to have an interface itself as a field in a structure. FC_PAD and FC_EMBEDDED_COMPLEX aren't types, they're just format codes, and padding is handled above anyway. The transmit_as and represent_as types haven't been implemented yet, and when they are I'm guessing they will be done similarly to the way user_types are done. Thanks.