
Bitfields Forever: Why We Need a C-Compatible Rust Crate - pcr910303
https://immunant.com/blog/2020/01/bitfields/
======
burfog
Native bitfield support is the only way. Everything else is awful to use.

There should be a way to specify an ABI by adding one or more attributes to
describe layout. Standard ones should include: natural alignment (by smallest
power of two), a specified minimum alignment, a specified maximum alignment,
do like Win32, do like Win64, do like the native 32-bit C, do like the native
64-bit C, big-endian byte order, big-endian bit order, bytes fill from MSB,
bits fill from MSB, little-endian byte order, little-endian bit order, bytes
fill from LSB, bits fill from LSB, padding is a compile error, padding is
undefined (for unsafe code only), padding is forced to zero, etc.

Rust can do better than C. Allow addresses of bitfields. Aligned bitfields of
reasonable size can be normal hardware pointers that are compatible with the
cross-language ABI, while other pointers can be restricted to rust code.

Don't try to support bitfields mapped to uncached hardware, but do support
implementing the layout of such hardware. The layout is useful to implement
emulators. The layout can also be useful with real hardware if the user does
his own copy-in and copy-out operations, with the bitfields being only used on
a RAM-based shadow copy of the hardware.

