diff options
author | Rich Felker <dalias@aerifal.cx> | 2019-10-17 15:40:16 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-10-17 15:55:15 -0400 |
commit | 97d35a552ec5b6ddf7923dd2f9a8eb973526acea (patch) | |
tree | 5cdbf3c58a4fb7eae7257f69f6d9d5d0aaee2a0e /include/features.h | |
parent | 00ec11d19e7c5fc99b5383233510c60a565cb01b (diff) | |
download | musl-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 'include/features.h')
0 files changed, 0 insertions, 0 deletions