|author||Rich Felker <firstname.lastname@example.org>||2019-10-17 15:40:16 -0400|
|committer||Rich Felker <email@example.com>||2019-10-17 15:55:15 -0400|
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/sh/bits/fenv.h')
0 files changed, 0 insertions, 0 deletions