russell-taylor
commented
9 years ago That's a leftover from the really old days when there was not a better way to find out. It was intended to be used in the internal code, but you're right that others may have latched on to it. I'm really opposed to pulling in boost just to get at endian-ness, but am certainly okay with replacing it with an extern bool reference and then moving the definition into the .C file. I think it was in the header originally to make it possible for compilers to inline it. It could also be replaced by #define to call a function that returns a bool that could be inlined.
rpavlik
The current approach uses a static variable declared in a header file, so we get a ton of these warnings, one in nearly every source file:
I'm not sure the current approach is even necessarily safe (think we should just be doing a
reinterpret_cast<const char *>since aliased access through a character type is explicitly permitted by the standard), but furthermore, on most platforms there's a preprocessor definition that can provide a more complete endianness answer at preprocessor time (cf. https://github.com/boostorg/predef/blob/develop/include/boost/predef/other/endian.h ), not just at optimize time (I'm hoping that variable gets optimized out...)Of course, the hairy part is, this is in a public header, and I don't know who is all consuming it. If nothing else, it should be moved to a separate header to be included if desired, and preferably it should be removed entirely except in cases where it's a really old/obscure machine and so the typical endianness definitions won't suffice.