Dear all,
I have this ultra simple strcture
typedef struct { uint8_t Hora; uint16_t Data1; } EEpromPaqueteDatosS;
When I do sizeof(EEpromPaqueteDatosS) it returns 4!!! But if I do the sizeof of the same structure with only one variable, in other words, with uint8_t variable it returns 1 and with uint16_t it returns 2.. but if the structure have the two variables it returns 4!!
Also if I copy the structure to a uint8_t vector I can found a strange byte in the middle.. like this:
EEpromPaqueteDatosS EEpromPaqueteDatos; uint8 data[4];
EEpromPaqueteDatos.Hora = 0x10; EEpromPaqueteDatos.Data1= 0x1020;
When I copy the structure to data, data is like 0x10, 0x??, 0x20, 0x10.. why this extra byte!!!!
Can anybody help me with this???
Thanks
#pragma pack(1)
This is the solution.
No, it is not "the" solution. It is what many people believe to be the only solution. Unfortunately, many of those people are wrong a good portion of the times. What these people ignore are the problem this so-called solution creates by itself.
The central issue though is that the problem this is supposed to solve typically isn't actually a problem at all. And even if does happen to be an actual problem in a given case, packing the structure may easily create more problems than it solves.
Been There. Done That.
It might seem like a good idea to try to match your comms protocol packets to packed 'C' structures like this - but it can, indeed, end up as more trouble than it's worth.
Bet to create functions to "serialise" and "de-serialise" your data: en.wikipedia.org/.../Serialization
www.lmgtfy.com
I never pack a structure intended for the cable or similar. Always an encode/decode or pack/unpack or serialize/unserialize explicitly implemented. It is 100% visible what happens, so you don't need to wonder when debugging. And the code can be moved to another processor with different byte order and the pack/unpack will still do as intended. So less code to rewrite when supporting multiple architectures.