swift-nav/libsbp

[C++] V4 struct packing

Closed this issue · 4 comments

Cerclique commented

I noticed that in V4 header files, structures are not packed anymore #pragma pack(push,1) / #pragma pack(pop).
Inside legacy directory, we can see the use of SBP_PACK_START/SBP_PACK_END or SBP_ATTR_PACKED in structure definition header files.

Is there any specific reason for this change ?

silverjam commented

Moving away from relying on structure packing was a goal of the v4 API — reason was that this makes it difficult to handle things like endianess (byte order) and non-fixed length messages in a portable manner. Packing and unpacking is now handled by the various _encode and _decode functions.

silverjam commented

Please reopen this issue or send a message to support@swiftnav.com if you have more questions!

poukill commented

Let's pretend I have a computer running on Windows 11 64bit that does the acquisition of the data and saves the "RAW" structures into a file.
Now I have another embedded PC running embedded linux (Ubuntu 20.04) with ARM architecture, trying to read the file and unpack the data for display.
Does your packing with "various _encode and _decode functions" cover that use case ?

silverjam commented

Let's pretend I have a computer running on Windows 11 64bit that does the acquisition of the data and saves the "RAW" structures into a file. Now I have another embedded PC running embedded linux (Ubuntu 20.04) with ARM architecture, trying to read the file and unpack the data for display. Does your packing with "various _encode and _decode functions" cover that use case ?

This is exactly what the v4 API was designed to handle. You would not write the C structures to file, but rather the raw frames. If we modify this example and say "the acquisition device was MIPS (big endian) device and the analysis machine was an x86 (little endian) machine" then it becomes clearer why this is necessary. The C structs on the MIPS machine will have numbers in big endian byte order, the x86 machine will have numbers in little endian byte order. If we were to store these C structs directly, you'd need to re-order the bytes in order for them to make sense on the x86 machine, which is precisely what the *_encode and *_decode functions are doing.