Hi, Looks like you sent this as HTML-only email, which are rejected by the mailinglist.
On Mon, 2017-08-21 at 12:57 +0200, Ulf Hermann wrote: > > Wouldn't this be a general problem for > > any struct that might be layed out differently but that we might > > map to some on-disk data structure? > > We should generally not rely on the layout of non-packed structs. The > compiler can insert padding in various places. I didn't find any > places where we do, though. I don't think the compiler can do that without breaking ABI. I believe we are very careful about the in-memory/on-disk struct layout matching. I am online now and found the documentation: https://gcc.gnu.org/onlinedocs/gcc/x86-Type-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields > If packed is used on a structure, or if bit-fields are used, it may > be that the Microsoft ABI lays out the structure differently than the > way GCC normally does. Particularly when moving packed data between > functions compiled with GCC and the native Microsoft compiler (either > via function call or as data in a file), it may be necessary to > access either format. > > This option is enabled by default for Microsoft Windows targets. OK, so it is x86-only and it only affects packed structs or if the struct contains bitfields. Otherwise the layout should be the same. So I do think your patch is correct. I don't think we ever use structs that contain bit-fields to map from disk to memory. Applied to master now. Thanks, Mark
