Avoid generating code with unaligned access error

[andrewdavidmackenzie]

In my "libproc-rs" project bindgen generates code that rustc stable/nightly warns will become an error in new releases.

error: reference to packed field is unaligned
 --> /Users/runner/work/libproc-rs/libproc-rs/target/debug/build/libproc-16321469bc40d5c5/out/osx_libproc_bindings.rs:3:673744
  |
3 | ...ze))) ; assert_eq ! (unsafe { & (* (:: std :: ptr :: null :: < proc_exitreasoninfo > ())) . eri_kcd_buf as * const _ as usize } , 24us...
  |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
  = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
  = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

error: could not compile `libproc` due to 110 previous errors
Error: Process completed with exit code 101.

Is there any way to avoid this, or is it something that could be worked on here in bindgen to avoid in the future?

[andrewdavidmackenzie]

It looks like the code producing the warning (future error) is in layout_tests for structs and using:

builder()
.layout_tests(false)

(see https://docs.rs/bindgen/latest/bindgen/struct.Builder.html#method.layout_tests) avoids generating that and avoids the issue.

Feel free to close this issue if you wish.

[kulp]

Thank you for the report.

The (generated, layout test) code that triggers this warning changed a few days ago, in #2203 (that change is not yet available on crates.io). See
5a01c55#diff-01720a19d4518b9c16feea9cefbee210a853a1c99d1e9b19aec23e72877e52f0L2195.

Optimistically, I think this means the warning will no longer fire in the next release. However, if it does, please reopen the issue.