Details
-
Bug
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
Description
Currently, padding layouts are just like value layouts - e.g. their inferred padding is == to their size.
In cases like these:
public static final MemoryLayout foo$LAYOUT = MemoryLayout.ofStruct(
MemoryLayouts.SysV.C_BOOL.withName("x"),
MemoryLayout.ofPaddingBits(56),
MemoryLayouts.SysV.C_INT.withName("v"),
MemoryLayout.ofPaddingBits(32)
).withName("foo");
This is problematic, because here we would have that the padding layout has an alignment of 56 - which will give the struct itself an alignment of 56 - since the struct size is 128 and 128 is not a multiple of 56, this layout is not considered to be well-formed by MemorySegment::allocateNative.
In cases like these:
public static final MemoryLayout foo$LAYOUT = MemoryLayout.ofStruct(
MemoryLayouts.SysV.C_BOOL.withName("x"),
MemoryLayout.ofPaddingBits(56),
MemoryLayouts.SysV.C_INT.withName("v"),
MemoryLayout.ofPaddingBits(32)
).withName("foo");
This is problematic, because here we would have that the padding layout has an alignment of 56 - which will give the struct itself an alignment of 56 - since the struct size is 128 and 128 is not a multiple of 56, this layout is not considered to be well-formed by MemorySegment::allocateNative.
Attachments
Issue Links
- links to
-
Review openjdk/panama-foreign/8