Closed dzmitry-lahoda closed 2 months ago
https://ziglang.org/documentation/master/#toc-packed-struct
so should i14 to occupy 14 bit in stuct or 16? zig seems may vary it. if rust would have arbitrary bit integers it can be next
struct iX<const value_bits, const memory_bits> where value_bits <= memory_bits ()
so one can tell exactly how much each stuct is in mem.
simplification would be just follow zig rules, so second constant is not needed.
also it should consider attrs from https://doc.rust-lang.org/reference/type-layout.html
or use like https://github.com/hashmismatch/packed_struct.rs
Reason one may have arbitrary bit primitives if he wants to use part of bits for other primitive or flags.
So proper design of such integer should make sure it is compatible with alignment and bit level packing
after searching rust-lang issues, found by jumping https://github.com/danlehmann/bitfield
https://ziglang.org/documentation/master/#toc-packed-struct
so should i14 to occupy 14 bit in stuct or 16? zig seems may vary it. if rust would have arbitrary bit integers it can be next
so one can tell exactly how much each stuct is in mem.
simplification would be just follow zig rules, so second constant is not needed.
also it should consider attrs from https://doc.rust-lang.org/reference/type-layout.html
or use like https://github.com/hashmismatch/packed_struct.rs
Reason one may have arbitrary bit primitives if he wants to use part of bits for other primitive or flags.
So proper design of such integer should make sure it is compatible with alignment and bit level packing