was Re: PIDL/IDL question(s) now RFC patch "support processing 'local' attribute"

[Noel Power]

On 07/08/14 15:36, Noel Power wrote:
> On 09/05/14 12:32, Noel Power wrote:
>> Hi,
>>
>> the following is a set of structures (simplified) expressed in c ( or
>> more likely pseudo-c ) that I wish to marshall. Using PIDL would be
>> ideal, I have tried but still I have some difficulty expressing the
>> structures so they would be marshalled in the correct way. Note: I don't
>> have control of the structures representation and cannot adjust them to
>> suit what is possible in idl. Note: I am pretty pidl disabled also so
>> any advice welcome
>>
>>   struct bounds {
>>       uint16 nelems;
>>       uint16 lbound;
>>   };
>>
>>   struct ndim_arraytype {
>>       uint16 ndims;
>>       uint16 somefield;
>>       struct bounds *bounds; /* bounds[ndims] */
>>       string values; /* values[elems] - where elems is calculated by
>> summing the nelems values from each bound struct stored above */
>>   };
>>
>> PROBLEM A: Although I can see howto to represent the bounds array above
>> (simple inline array) in idl I can't see how to do that for the elements
>> array where the number of elements is determined at runtime from the
>> contents of the bounds array. Aspirationally I would like to do
>> something like
>>
>>   typedef [public] struct {
>>       uint16 ndims;    
>>       uint16 somefield;    
>>       struct bounds bounds[ndims]
>>       string values[custom_fn(bounds, ndims)];
>>   } ndim_arraytype;
>>
>> and indeed the generated code looks like it would do what I require,
>> however the custom_fn is obviously undefined and therefore wont build. I
>> can I guess create a new source & header file that contains the custom
>> function I need and build it with the generated ndr_xyz files, but is
>> this the correct thing to do?, am I depending on some unintentional
>> behaviour by using 'variant elements[custom_fn(bounds, ndims)];'? or
>> indeed is there a better way to do this ?
>
Alternatively there is the 'local' attribute that MIDL accepts ( note: I
am not a MIDL user but just was playing a little with it because the
more I thought about it, the more it seemed there should be an option to
do something similar to above) The following patches add *simple*
support for processing the 'local' attribute

a) in the interface attribute list
&
b) in the function attribute list

Essentially the 'local' attribute generates a non-remote/local function
prototype in the header file, more details in the commit message.

Additionally it would be nice to get some f/b regarding the use of
constructs like

    'variant elements[custom_fn(bounds, ndims)];'

which while not valid from the MIDL point of view seems to be accepted
by pidl, IMHO the ability/flexibility to be able to generate code
outweighs conformity to MIDL behaviour (and there are already afaics
existing examples of that like support for inline arrays)

thanks,
Noel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-allow-pidl-process-local-function-attribute.patch
Type: application/mbox
Size: 1839 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140821/34b67c61/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-allow-pidl-process-interface-attribute-list-item-loc.patch
Type: application/mbox
Size: 3947 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140821/34b67c61/attachment-0001.bin>