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

[Noel Power]

<sigh> I accidentaly sent this private (twice) and not to the list

On 22/08/14 00:12, Jelmer Vernooij wrote:
> On Thu, Aug 21, 2014 at 08:52:18PM +0100, Noel Power wrote:
>> On 21/08/14 17:45, Jelmer Vernooij wrote:
>>> On Thu, Aug 21, 2014 at 11:25:55AM +0100, Noel Power wrote:
>>>> 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.
>>> I'm not sure if I understand your use case here (for [local]).
>> Sorry, I thought the example (see verbage & 'struct ndim_arraytype'
>> above) was clear, the number of elements in the inline array 'values'
>> can only be determined at runtime. The calculation needs to be done by a
>> custom function, while one can write an expression for the inline array
>> member e.g. like
>>
>>      string values[custom_fn(bounds, ndims)];
>>
>> and the generated code is all good, but 'custom_fn' does not exist,
>> compiling the generated ndr_[ifname].c will fail because there is no
>> prototype. The 'local' attribute allows the prototype to be generated.
> Ah, I see.
>
> We've generally handled this by using the helper() attribute on
> interfaces to include extra header files.
>
> I'm not opposed to supporting the [local] attribute, but we should
> think carefully about its semantics. The way this patch implements it,
> the semantics of [local] functions is wildly different from that of
> non-local functions, which I don't think is the intent.
>
> Jelmer