On Wed, Apr 13, 2016 at 7:19 AM, Peter Dimov
Beman Dawes wrote:
But to follow the same pattern as the conversion functions, the interface
would look like this:
float endian_reverse(float x) noexcept;
but like you and whoever raised the issue originally, I don't want to bet on that working.
Passing an arbitrary sequence of bytes by value should in principle be avoided even for int because of trap representations, so adding float support may provide the motivation to fix that as well.
The correct type of a wrong-endian-int or a wrong-endian-float is unsigned char[sizeof(int)] or unsigned char[sizeof(float)], not int or float.
Agreed. The traditional conversion approach of passing and returning an int or whatever is essentially an undiscriminated union: union here_be_dragons { int maybe_this; unsigned char[4] or_maybe_this; }; Maybe the endian conversion functions should stop perpetuating such insanity. --Beman