
Daniel Krügler wrote:
Pfligersdorffer, Christian wrote: [..]
b) The version of the portable binary library that is currently part of the package uses the endianness on the machine which create the archive. On reading the archive, the endienness is swapped around if and only if the the endienness of the reading machine is different than that contained in the archive. The endiennes of the archive is stored in the archive header. The idea is that the most likely reader of an archive is one using the same endienness of the creator. Also, Endienness of the archive being created can be overridden during archive construction. This is basically a way of keeping myself out of any endieness debate.
I see. The issue also came up in the lengthy cross-platform binary serialization a few weeks ago. I personally understand one would like to choose the endianness but what great benefits does it bear? We chose little endian because it is most widely used and was convenient to implement. I guess it would be a minor modification to allow for both but I don't deem it neccessary.
IMO taking care of the endianness should be an important aspect of a portable binary library.
Just my 2 cents,
Make that 4 cents. :-) I agree with Robert's approach on this one. I'd go even further though and make the endian-ness part of the archive type. Or at least a required constructor parameter separate from the other flags. Some of our engineers were bitten when the endian-ness defaulted to the build machine's endian-ness. Lot's of problems with Mac OS universal binaries. Jeff