So for padding, it sometimes depends on how your compiler works, but usually, it doesn’t pack bytes by default - that needs to manually be done. Otherwise, a uint32 followed by 2 uint16s, for example, will take up the space for 3 uint32s (in a 32-bit native compiler). If you manually specify packing (implemented differently depending on your compiler and such), then it will pack those all properly into just 2 uint32s.
I do imagine 24 bits followed by 16 more in a bit field for a 32-bit number would potentially cause problems. But it’s late here and I could certainly be wrong so take that with a grain of salt.
That also said, I typically don’t use bitfields directly in structures - it’s not usually good practice, at least where I work. I’d either do a uint8[3] or use a whole uint32 that is a union, and in the union would be your :24 followed by a reserved : 8, if that makes any sense. It’s sometimes worth it to leave a few extra bytes in there just from an organization standpoint.
So for padding, it sometimes depends on how your compiler works, but usually, it doesn’t pack bytes by default - that needs to manually be done. Otherwise, a uint32 followed by 2 uint16s, for example, will take up the space for 3 uint32s (in a 32-bit native compiler). If you manually specify packing (implemented differently depending on your compiler and such), then it will pack those all properly into just 2 uint32s.
I do imagine 24 bits followed by 16 more in a bit field for a 32-bit number would potentially cause problems. But it’s late here and I could certainly be wrong so take that with a grain of salt.
That also said, I typically don’t use bitfields directly in structures - it’s not usually good practice, at least where I work. I’d either do a uint8[3] or use a whole uint32 that is a union, and in the union would be your :24 followed by a reserved : 8, if that makes any sense. It’s sometimes worth it to leave a few extra bytes in there just from an organization standpoint.