Tomas Puverle wrote:
This is a good point. And this is not as unusual as you may think, even on IEEE 754 machines. For example, on some compilers on Intel machines, sizeof(long comes in at 12 bytes (even though long double is only 80 bits), essentially meaning that the last two bytes are garbage when the data is in memory.
However, I am not completely sure that this falls within the realm of an endian library. If, as in your example, the program cannot move the data from its internal registers to memory without modifying it, what would you suggest the endian should library do?
I was mainly pointing out the function that Robert Stewart was proposing or using as an example:
template <class T, class U> T big_endian_cast(U);
I did the same thing many years ago (when writing an endian swapping utility), and noticed that when returning by value, the fp normalization would occur, causing silent "changing of the internal bits". Floating point values could be "in-place" swapped, but this was the only safe usage (I.e. after the "in-place" swap, the values would have to be sent across the network or written to disk, etc). The brittleness with swapping fp values is a subtle and non-obvious problem. The best endian solution would be one that includes safe and portable binary floating point approaches, although I'm not familiar enough with the possibilities to know how much effort that entails. At the least, any endian facilities need to either disallow or cause warnings to occur (really BIG and nasty warnings would be best), when used with fp values. I ended up writing endian facilities that were, in effect, "take this stream of bytes, and return a value correctly endian swapped (and safe) for use by the app". For example, the function above was something like: template <typename T> T extract_and swap_from_stream(const char*); It would be used as: val = extract_and_swap_from_stream<int32_t>(buf); This was project specific (as part of a general marshalling library), and has drawbacks (e.g. it assumed certain endian orderings in the incoming stream). Cliff