Thanks for the advice and taking a look at this.  I will update my schema 
to use structs instead of groups.

On Thursday, June 23, 2016 at 3:40:03 PM UTC-4, Kenton Varda wrote:
>
> Ouch, that seems bad. Thanks for the investigative work and clear repro 
> case. I'm looking at this now.
>
> So far it seems like the bug is somehow triggered by having such a deeply 
> nested union/group hierarchy. FWIW, I would generally recommend using 
> separate structs rather than groups unless the group is trivial or is 
> necessary for backwards compatibility.
>
> That said, that's not an excuse for this bug.
>
> -Kenton
>
> On Thu, Jun 23, 2016 at 11:44 AM, <[email protected] <javascript:>> wrote:
>
>> Hi,
>>
>> I came across a weird behavior when using capnproto and was wondering if 
>> there was something I'm doing wrong or if this is a potential bug in the 
>> system.  Consider the following schema that I created:
>>
>> @0xb9e4b6b777f18b59;
>>
>> struct Fields {
>>     field1 @0 :Int32;
>>     field2 @1 :Int64;
>>     field3 @2 :Int32;
>>     eventType : union {
>>         unknownEvent @3: Void;
>>         sampleEvent : group {
>>             field4 @4 :Int32;
>>             request : union {
>>                 field5 @5: Void;
>>                 field6 : group {
>>                     field7 @6 :Int16;
>>                     field8 @7 :Int32;
>>                     field9 @8 :Float64;
>>                     field10 @9 :Int32;
>>                 }
>>             }
>>         }
>>     }
>> }
>>
>>
>> I noticed that when I set field8 = 100 and then field10 = 200, field8 
>> also becomes 200.  I decided to look at the byte layout that this schema 
>> created using capnp compile -ocapnp and saw the following:
>>
>> # sample.capnp
>>
>> @0xb9e4b6b777f18b59;
>>
>> struct Fields @0x87848103d33eda11 {  # 40 bytes, 0 ptrs
>>
>>   field1 @0 :Int32;  # bits[0, 32)
>>
>>   field2 @1 :Int64;  # bits[64, 128)
>>
>>   field3 @2 :Int32;  # bits[32, 64)
>>
>>   eventType :group {
>>
>>     union {  # tag bits [128, 144)
>>
>>       unknownEvent @3 :Void;  # bits[0, 0), union tag = 0
>>
>>       sampleEvent :group {  # union tag = 1
>>
>>         field4 @4 :Int32;  # bits[160, 192)
>>
>>         request :group {
>>
>>           union {  # tag bits [144, 160)
>>
>>             field5 @5 :Void;  # bits[0, 0), union tag = 0
>>
>>             field6 :group {  # union tag = 1
>>
>>               field7 @6 :Int16;  # bits[192, 208)
>>
>>               field8 @7 :Int32;  # bits[224, 256)
>>
>>               field9 @8 :Float64;  # bits[256, 320)
>>
>>               field10 @9 :Int32;  # bits[224, 256)
>>
>>             }
>>
>>           }
>>
>>         }
>>
>>       }
>>
>>     }
>>
>>   }
>>
>> }
>>
>> Notice how field 8 and field10 occupy the same memory region!  Am I doing 
>> something wrong here or is this a bug?  I tried this on the latest version 
>> of capnproto as well as version 0.5.2 and saw the same behavior.  Any 
>> feedback would be greatly appreciated!
>>
>> Thanks,
>> -David
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Cap'n Proto" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> Visit this group at https://groups.google.com/group/capnproto.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.

Reply via email to