On Mon, 25 Nov 2024 at 09:39, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On Mon, Nov 25, 2024 at 10:34 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > IMHO we need to have confidence not only in the current state of the code, > > but also that we're not going to accidentally regresss it in the future. > > This is what the gcc_struct attribute gives us confidence in. > > Yes, as you say below the "solution" to that could be simply to avoid > bitfields. They are problematic anyway for big-endian machines, see > the commit that Thomas pointed out. Unfortunately it's a > human-enforced solution, but then it is already human-enforced for > endianness issues.
Mmm. The closest we get to auto-enforcement is CI on the big-endian host, which requires that there's a test case that exercises the struct. > > As an alternative is it practical for us to eliminate all bitfields > > from our structs ? > > It is (at least for guest-visible structs), but it is a lot of work > and I don't think it's reasonable for it to block clang enablement on > Windows. It is such a pity that C does not make it easy to have a portable way to say "this is a struct that must match a particular layout for ABI compatibility and it should be like this exactly regardless of host system details, even if that isn't what you would 'naturally' use". Does Rust provide any better facilities for this? -- PMM
