On Sun, Oct 26, 2014 at 04:04:01PM -0400, David Michael wrote: > I'm not 100% sure if __THW_LITTLE_ENDIAN__ will ever be defined, so > I'd be okay with dropping those references completely. There is a > recent version of the compiler for little endian Linux distributions, > but I haven't found the documentation for it. (The product > documentation still seems to only refer to the big endian Linux > version.) The compiler's macro may be redundant in this case anyway, > since Linux systems should have <bits/endian.h> supplying that > information. > > I only used both macros for completeness; the __THW_BIG_ENDIAN__ macro > (defined to 1 on z/OS and AIX) is what I actually needed here. z/OS > doesn't seem to have any other compile-time byte order indicator, > short of testing for the OS itself.
Thanks for the explanation. > Would you prefer the two-line patch to only test for the big endian > macro, I think that's OK, as long as the #else case barfs as it does now (i.e., doesn't silently choose little-endian). > or maybe just test for __MVS__ to look at the OS? If the OS's you're testing on all provide a big-endian marker like __THW_BIG_ENDIAN__, that seems preferable to me to use, as it's more explicit. We can deal with similar little-endian systems if and when somebody sees one in the wild (and your explanation that it would probably hit the Linux <bits/endian.h> check first makes sense to me). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
