[foreign] RFR 8217784: Ignore anonymous bitfields so they are handled as padding

Jorn Vernee jbvernee at xs4all.nl
Fri Jan 25 22:43:49 UTC 2019


I think it's okay. The anonymous bitfield is still handled in the sense 
that libClang will use it to compute the offset for the next named 
field. We just derive the padding from that offset instead of trying to 
compute it ourselves from the anonymous bitfield. Handling the anonymous 
bitfield manually would at first glance also seem to make the code a bit 
more complex, since we are breaking the assumption that we can get the 
offset of any field we are processing. Ignoring the anonymous bitfield 
just kind of works out nicely.

The change in UnionLayoutComputer looks kind of magic. There might be 
other reasons why the computed size of a union is smaller than the size 
reported by libClang. An anonymous bitfield is the only reason I could 
think of, so that's why I wrote that specific comment there. The change 
in implementation is because the previous implementation was incorrect 
AFACT; if the computed size is too small, we need a padding member with 
the expected size of the union, since all fields of a union overlap.

Jorn

Maurizio Cimadamore schreef op 2019-01-25 22:24:
> The patch is functionally good, I just wonder if it's too magic - e.g.
> wouldn't be better if the record computer processed the anonymous
> bitfield (so that the correct padding can be added) instead of relying
> on the right thing to happen (which will be fragile if e.g. the impl
> changes a bit) ?
> 
> Maurizio
> 
> On 25/01/2019 19:18, Jorn Vernee wrote:
>> Good catch. I kinda glossed over unions since I thought there would be 
>> no point in having anonymous bitfields in a union, since there is no 
>> need for padding - but on second thought, these could be used to 
>> manually widen the type. Any ways, the compiler seems to allow 
>> anonymous bitfields in unions, so it's good to support that as well.
>> 
>> Updated webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8217784/webrev.01/
>> 
>> Jorn
>> 
>> Maurizio Cimadamore schreef op 2019-01-25 19:25:
>>> Looks good - but what happens with unions? I'm worried we'd get a
>>> similar failure there...
>>> 
>>> Maurizio
>>> 
>>> On 25/01/2019 13:52, Jorn Vernee wrote:
>>>> Hi,
>>>> 
>>>> From the bug description:
>>>> 
>>>> Jextract fails on the following example:
>>>> 
>>>> ```
>>>> struct Foo {
>>>>     unsigned int x: 1;
>>>>     int :7;
>>>>     unsigned int y: 8;
>>>>     int :16;
>>>>     int z;
>>>> };
>>>> ```
>>>> 
>>>> The current code tries to look up the second field, but because it 
>>>> has no name this throws an illegal field name error.
>>>> 
>>>> ---
>>>> 
>>>> I've fixed this by ignoring anonymous bitfields, since the 
>>>> StructLayoutComputer inserts padding automatically before the next 
>>>> field.
>>>> 
>>>> Please review the following.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217784
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8217784/webrev.00/
>>>> 
>>>> Thanks,
>>>> Jorn


More information about the panama-dev mailing list