5 ms·
There's enough wiggle room in the standard that two compilers would be happy making two compliant but still different physical layouts for the same struct decla
by kabdib 8y ago
There's enough wiggle room in the standard that two compilers would be happy making two compliant but still different physical layouts for the same struct declaration. I'm not even worrying about cross-platform issues or bitfields yet.
You can get away with directly writing a struct for simple structs, but eventually it will bite you.
- hedora 8y agoPacked structs are reasonably standard (even gcc and visual studio can be made to pack in the same way using the same syntax these days). The remaining issue is endianness, but you can configure ARM to match x86 at boot so shrug. Also, if I tell any reasonably experienced developer my protocol sends a packed struct with these fields: uint8_t version uint16_t reserved uint8_t op int32_t status uint32_t data_length // void data[] They’ll be able to write a correct deserializer in pretty much any language, and can probably write it in ~ 10 lines of code. I agree that packed structs can be tricky, but they’re much better than the vast majority of serialization libraries I’ve dealt with (including all of the open source ones, and I’ve used all the usual suspects).
- Gibbon1 8y agoMy experience with packed structs is there really aren't any gotcha's. Either works or not. The big annoyance is network people all use big endian probably just to spite everyone else.
- shaklee3 8y agoWhy would it be to spite everyone? Big endian is network order by definition. It's hard-coded into every asic in switches and routers for decades. If you don't use big endian your packets won't even make it to where you want. Of course, your own payload can do whatever you want as long as you know with 100% certainty nobody else will ever want to talk to your application and get confused.
- Gibbon1 8y agoConsider the lorawan spec which was written in the last 5 years. The stack is designed to be implemented in software on small 32 bit microcontrollers which are _all_ little endian. And it's big endians. The people that wrote that spec knew that and went with big endian anyways. Also I work with people that do network hardware. They can't care less about little or big endian. Makes no difference to them.
- blattimwind 8y ago> The remaining issue is endianness, but you can configure ARM to match x86 at boot so shrug. ARM in BE mode is pretty rare / nonexistent. Small MIPS chips still float around in mostly low-end networking gear, though, and those do tend to run in BE.