[Patch] fix IDL hang V2

[Noel Power]

On 22/08/14 12:56, Jelmer Vernooij wrote:
> On Fri, Aug 22, 2014 at 10:54:29AM +0100, Noel Power wrote:
>
[...]
>
>>> If there's a struct member that is a pointer, then
>>> can_contain_deferred should never check whether that member itself can
>>> contain a deferred at all. How does a loop occur here?
>> I don't believe that I said it did (although in fairness I did think it
>> might), but really I just was trying to understand the point you were
>> making with the psuedo code you had
> Your patch was changing this function. If it doesn't have a loop in
> it, then why does it need to be changed?
all I can say it that it used to loop, the explanation is probably a bug
in a previous incarnation of the patch, I wouldn't have changed it on a
whim (and I remember it looping) removing that part of the patch and
retrying I see indeed it is not necessary (thanks for catching that)
>
>>> FWIW I can compile the second IDL file without problems here, without
>>> your patch:
>> sure, so as can I. But....
>>
>> interface hang
>> {
>>     typedef [public] struct {
>>         uint32 count;
>>         bar a[count];
>>         hyper t;
>> } foo ;
>>
>>     typedef [public] struct {
>>         foo b;
>>     } bar;
>> }
>>
>> will also hang (and could be considered maybe a better mininal
>> representation of the structure I originally has a problem with)
> How many alignment bytes would you expect to use before "a" in this
> case? None? Eight?
actually 4, iiuc I will get 8 due to the hyper (which I can split into 2
words to make it work the way I want), sofar the default NDR encoding
seems to be working out, maybe that is by luck (although I have been
able to unmarshall a fair number of messages exported from wireshark
without difficulty) is it currently possible to selectively influence
the alignment of members (e.g. turn it off or force to a particular
alignment)


Noel