Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Bitfields Forever: Why We Need a C-Compatible Rust Crate (immunant.com)
4 points by goranmoomin on Jan 28, 2020 | hide | past | favorite | 1 comment


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: