You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How we should represent the bitfields in Haskell? As unpacked fields, or more closely, packing bitfields as in C?
The former is simpler, but fora struct with 64 single bit flags it won't be great; latter is more complicated (e.g. Rust creates virtual interface; in GHC the HasField comes to mind, and maybe our own class for setters for time-being, until GHC gets one).
An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.
When we generate Storable instances, field offsets are for the specific version of Clang/LLVM used. If users build with a different compiler/version, perhaps our generated Storable instances could be inconsistent? Should we take measures to address this? Our generated tests should catch it, at least.
No description provided.
The text was updated successfully, but these errors were encountered: