Incorrect alignment of types on x86_64-apple-darwin

[gnzlbg]

The types:

• kevent
• shmid_ds

should have 4-byte alignment, but on 64-bit macosx they have 8-byte alignment.

This means that:

• the size of these structs is wrong
• the offset of some fields within the struct is wrong

I tried to use #[repr(align(4))] on these to enforce the alignment, but this did not change anything.

See https://github.com/rust-lang/libc/pull/912/files#diff-747c41e91bd79d9208c2953b72047176R418

[bitshifter]

What do the C structs look like for these on macos? Do they apply some packing to lower alignment on 64bit?

[gnzlbg]

See here: https://github.com/phracker/MacOSX-SDKs/blob/9fc3ed0ad0345950ac25c28695b0427846eea966/MacOSX10.13.sdk/usr/include/sys/ipc.h

You can search for the struct names in the MacOSX10.13.sdk specified there, the struct themselves have no special annotations, but the header files do have a #pragma pack(4).

[bitshifter]

Ah thanks, my google-fu was failing me.

[gnzlbg]

Yeah MacOSX headers are not really googleable. That github repo with all headers for all MacOSX versions is just golden.

[bitshifter]

I was thinking about this issue and your example in rust-lang/rust#48159 you could put a [repr(packed)] struct inside an [repr(align(4))] struct to get something that will work for FFI, e.g. https://play.rust-lang.org/?gist=7c5268152634aeec794c45cc4480d066&version=beta. Pretty ugly but it should allow you to progress before [repr(packed(4))] support is merged. Depending on the struct you might still need to manually pad some fields.

[gnzlbg]

Yes, an "easier" alternative is to just use an opaque type (e.g. an array of bytes) and the appropriate repr(align), and then just have setters/getters for the fields.

I think we'll just wait till repr(packed(N)) is merged, hopefully sooner rather than later.

[kristate]

ref for repr(packed(N)): rust-lang/rust#33158

[gnzlbg]

packed is now used when building from within std - i'll open another issue to track the packed(N) stabilization