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

[Noel Power]

On 22/08/14 11:10, Noel Power wrote:
> <sigh> I accidentaly sent this private (twice) and not to the list
>
> On 22/08/14 00:12, Jelmer Vernooij wrote:
[...]
>>> 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.
<sigh> thanks!! missed that, didn't see it, would have saved me a pile
of grief trying to do the same thing 2 different ways :-(
>>
>> 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.
not sure what you mean by "semantics of [local] functions is wildly
different from that of non-local functions" some brief experimentation
with midl seemed to bear out just a plain c like prototype is generated
(idls with interface attribute 'object' seem to be an exception), e.g.
just using the function attribute like in the example in the commit
(something like)

[
    uuid("dc12a681-737f-11cf-884d-00aa004b2e24")
]
interface local_object_procs
{
    [local] void MyLocalObjectProc(int param1, char * param2);
    void MyRemoteObjectProc(int param1, char * param2);
}

then stubs and local (plain c-func prototype are generated (see attached
for the idl and files resulting from midl). It seems when 'object' is
also present then the code generated for the local function is not just
the simple prototype (I confess I don't know exactly what should be
produced in this case) but there are already idl files in the tree with
this combination, in this case I ignore the local attribute and let pidl
do what it use do previously (note: I did check the before and after
output of the generated code to ensure that it is the same as before)
There is more info here
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366853%28v=vs.85%29.aspx.
It's sure that more checks regarding legal combinations etc good be
done, there are bound to be edge cases but this is just a *simple*
implementation. If the patch is useful then great I'd be happy if it
gets used, if not well it seems I don't need this now with the 'helper'
attribute

thanks,
Noel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: midl-local-example.zip
Type: application/zip
Size: 5851 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140822/22071fc9/attachment-0001.zip>