Comment by jstimpfle
6 hours ago
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
> struct layout is well specified
Technically that's not true at least for booleans and enums, the C standard doesn't define specific sizes for those, and on MSVC it's quite common to force enums to 32-bits by defining a dummy enum item with the value 0x7FFFFFFF (not sure if that's still actually an issue, but without this hack MSVC used to pick a smaller size (like 16-bits).
Specified by whom? Not the C standard for sure. It is indeed soecified by individual ABIs, and ABIs don't tend to do anything too weird, but that's another question.
looks like I was wrong, but here is the de-facto standard I was relying on over the years ;-). Not that I've memcpied many structs to file directly btw. http://www.catb.org/esr/structure-packing/
The general struct layout algorithm is that you lay out the first member at the address of the struct (this is guaranteed by C), and then subsequent fields in order (also guaranteed by C). What isn't guaranteed is how fields get their alignment, in particular shenanigans you can do with allocating fields in the padding of their prior field, and bitfields in general are horribly underspecified.
In practice, C doesn't do any padding shenanigans, but C++ does (but only for non-POD structs, and then you discover there's several slightly different definitions that mean basically "POD", so have fun predicting which one is the one that actually matters for your use case).
If you modify or even just move fields around the struct that also changes the way they are serialized...
You really need a serializer for this sort of thing because it can also include forwards compatibility of your data structures.
It's typical to only append fields when you do this.
sure, if you change the struct, it will now be different.