Interesting! I wonder what other complexities could arise from this. For example, if I were to serialize and stream a record from an architecture with different alignment, and pump the data directly into a record, would I get what I expected when querying the contents? My knowledge is lacking in this. When reading/writing various binary formats from/to a disk into/from records, I always set my record to be packed for fear of the byte alignment of an unpacked record resulting in unexpected values.
Can anyone tell me off the top of their heads if my fears are justified? I think some research is in order
EDIT : OK. from what I've read, you should not stream an unpacked, boundry aligned record to a file or across a network unless you can ensure that it will be read back or recieved with the same byte alignment. the padding of the record will get written too!
For streams/writing to a hard disk (or any other such bulk transfer of a record to some form of media) you should always use packed records! (unless you want to read that data on multiple architechures such as PowerPC, Arm etc, see 'endiness' below)
you should only use non packed records if they will only ever live in memory, at run time. And should do in this situation because of the performance improvments offered by byte aligned data.
In situations where you want the speed of byte aligned but still want to write that data out to a disk, it's highly advisable that you write it an element at a time, rather than just streaming from the address of the record using the size of the record.
If you are writing your code to run on architectures with different endiness you should never just stream a record, always break it down into it's component parts for endiness conversion!
I hope this has added to the discussion
Reply With Quote
Bookmarks