summaryrefslogtreecommitdiff
path: root/arch/s390x/bits/user.h
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2019-10-17 15:40:16 -0400
committerRich Felker <dalias@aerifal.cx>2019-10-17 15:55:15 -0400
commit97d35a552ec5b6ddf7923dd2f9a8eb973526acea (patch)
tree5cdbf3c58a4fb7eae7257f69f6d9d5d0aaee2a0e /arch/s390x/bits/user.h
parent00ec11d19e7c5fc99b5383233510c60a565cb01b (diff)
downloadmusl-97d35a552ec5b6ddf7923dd2f9a8eb973526acea.tar.gz
move __BYTE_ORDER definition to alltypes.h
this change is motivated by the intersection of several factors. presently, despite being a nonstandard header, endian.h is exposing the unprefixed byte order macros and functions only if _BSD_SOURCE or _GNU_SOURCE is defined. this is to accommodate use of endian.h from other headers, including bits headers, which need to define structure layout in terms of endianness. with time64 switch-over, even more headers will need to do this. at the same time, the resolution of Austin Group issue 162 makes endian.h a standard header for POSIX-future, requiring that it expose the unprefixed macros and the functions even in standards-conforming profiles. changes to meet this new requirement would break existing internal usage of endian.h by causing it to violate namespace where it's used. instead, have the arch's alltypes.h define __BYTE_ORDER, either as a fixed constant or depending on the right arch-specific predefined macros for determining endianness. explicit literals 1234 and 4321 are used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no danger of getting the wrong result if a macro is undefined and implicitly evaluates to 0 at the preprocessor level. the powerpc (32-bit) bits/endian.h being removed had logic for varying endianness, but our powerpc arch has never supported that and has always been big-endian-only. this logic is not carried over to the new __BYTE_ORDER definition in alltypes.h.
Diffstat (limited to 'arch/s390x/bits/user.h')
0 files changed, 0 insertions, 0 deletions