about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* convert ioctl time64 fallbacks to table-driven frameworkRich Felker2019-12-181-17/+66
| | | | | | | | with the current set of supported ioctls, this conversion is hardly an improvement, but it sets the stage for being able to do alsa, v4l2, ppp, and other ioctls with timespec/timeval-derived types. without this capability, a lot of functionality users depend on would stop working with the time64 switchover.
* fix regression in ioctl definitions provided by arch/generic bitsRich Felker2019-12-181-0/+1
| | | | | | | | commit b60fdf133c033d4ad6b04a8237f253563fae5928 broke the SIOCGSTAMP[NS] ioctl fallbacks introduced in commit 2e554617e5a6a41bf3f6c6306c753cd53abf728c, as well as use of these ioctls, by creating a situation where bits/ioctl.h could be included without __LONG_MAX being visible.
* hook recvmmsg up to SO_TIMESTAMP[NS] fallback for pre-time64 kernelsRich Felker2019-12-172-6/+14
| | | | | | | | | | | | | | | | | always try the time64 syscall first since we can use its success to conclude that no conversion is needed (any setsockopt for the timestamp options would have succeeded without need for fallbacks). otherwise, we have to remember the original controllen for each msghdr, requiring O(vlen) space, so vlen must be bounded. linux clamps it to IOV_MAX for sendmmsg only (not recvmmsg), but doing the same for recvmmsg is not unreasonable, especially since the limitation will only apply to old kernels. we could optimize to avoid trying SYS_recvmmsg_time64 first if all msghdrs have controllen zero, or support unlimited vlen by looping and emulating the timeout logic, but I'm not inclined to do complex and error-prone optimizations on a function that has so many underlying problems it should really never be used.
* implement SO_TIMESTAMP[NS] fallback for kernels without time64 versionsRich Felker2019-12-175-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the definitions of SO_TIMESTAMP* changed on 32-bit archs in commit 38143339646a4ccce8afe298c34467767c899f51 to the new versions that provide 64-bit versions of timeval/timespec structure in control message payload. socket options, being state attached to the socket rather than function calls, are not trivial to implement as fallbacks on ENOSYS, and support for them was initially omitted on the assumption that the ioctl-based polling alternatives (SIOCGSTAMP*) could be used instead by applications if setsockopt fails. unfortunately, it turns out that SO_TIMESTAMP is sufficiently old and widely supported that a number of applications assume it's available and treat errors as fatal. this patch introduces emulation of SO_TIMESTAMP[NS] on pre-time64 kernels by falling back to setting the "_OLD" (time32) versions of the options if the time64 ones are not recognized, and performing translation of the SCM_TIMESTAMP[NS] control messages in recvmsg. since recvmsg does not know whether its caller is legacy time32 code or time64, it performs translation for any SCM_TIMESTAMP[NS]_OLD control messages it sees, leaving the original time32 timestamp as-is (it can't be rewritten in-place anyway, and memmove would be mildly expensive) and appending the converted time64 control message at the end of the buffer. legacy time32 callers will see the converted one as a spurious control message of unknown type; time64 callers running on pre-time64 kernels will see the original one as a spurious control message of unknown type. a time64 caller running on a kernel with native time64 support will only see the time64 version of the control message. emulation of SO_TIMESTAMPING is not included at this time since (1) applications which use it seem to be prepared for the possibility that it's not present or working, and (2) it can also be used in sendmsg control messages, in a manner that looks complex to emulate completely, and costly even when running on a time64-supporting kernel. corresponding changes in recvmmsg are not made at this time; they will be done separately.
* signal to kernel headers that time_t is 64-bitRich Felker2019-12-171-0/+1
| | | | | | | | | | | | | | | linux/input.h and perhaps others use this macro to determine whether the userspace time_t is 64-bit when potentially defining types in terms of time_t and derived structures. the name __USE_TIME_BITS64 is unfortunate; it really should have been in the __UAPI namespace. but this is what was chosen back in v4.16 when first preparing input.h for time64 userspace, presumably based on expectations about what the glibc-internal features.h macro for time64 would be, and changing it now would just put a new minimum version requirement on kernel headers. the __USE_TIME_BITS64 macro is not intended as a public interface. it is purely an internal contract between libc and Linux uapi headers.
* fix null pointer dereference in setitimer time32 compat shimRich Felker2019-12-081-4/+6
| | | | | | | this interface permits a null pointer for where to store the old itimerval being replaced. an early version of the time32 compat shim code had corresponding bugs for lots of functions; apparently setitimer was overlooked when fixing them.
* arm: avoid conditional branch to PLT in sigsetjmpAndre McCurdy2019-12-071-2/+3
| | | | | The R_ARM_THM_JUMP19 relocation type generated for the original code when targeting Thumb 2 is not supported by the gold linker.
* riscv64: fix fesetenv(FE_DFL_ENV) crashRuinland ChuanTzu Tsai2019-12-071-1/+4
| | | | | When FE_DFL_ENV is passed to fesetenv(), the very first instruction lw t1, 0(a0) will fail since a0 is -1.
* update contributor nameAda Worcester2019-12-072-1/+2
| | | | | This changes my name in the COPYRIGHT file, and adds a .mailmap entry for my new name.
* ppc: add configure check for older compilers erroring on 'd' constraintrofl0r2019-11-053-2/+11
|
* fix build regression on mips64 due to endian.h removalRich Felker2019-11-051-0/+2
| | | | | | | | | | | | | | | | commit 4d3a162d001a93edd285fb6603a883c30ae553ba overlooked that the mips64 reloc.h dependent on endian.h not only for setting the ABI ldso name to match the byte order, but also for use of the byte swapping macros. they are needed to override R_TYPE, R_SYM, and R_INFO, to compensate for a mips "quirk" of always using big endian order for symbol references in relocations. part of that commit canot be reverted because the original code was wrong: it's invalid to define _GNU_SOURCE or any feature test macro in reloc.h, or anywhere except at the top of a source file. however, thanks to commit 316730cdc7a330cddf288b4e5c1de5daa64e19f4, the feature test macro is no longer needed to access the endian-swapping macros, so simply bringing back the #include directive suffices.
* fix failure to build time32 compat shims with out-of-tree buildsRich Felker2019-11-041-1/+1
| | | | | | | commit de90f38e3b105802655d19d965d66335d25d59ef omitted $(srcdir) from the makefile include pathname it added. since the include directive was prefixed with - to make it optional (for archs that don't use it), the failure to find arch/$(ARCH)/arch.mak was silent.
* fix time64 link regression of dlsym stub for static-linked programsRich Felker2019-11-031-0/+4
| | | | | | | | | in commit 22daaea39f1cc5f7391f0a5cd84576ffb58c2860, the __dlsym_redir_time64 function providing the backend for __dlsym_time64 was defined only in the dynamic linker, and thus was undefined when static linking a program referencing dlsym. use the same stub_dlsym definition that provides __dlsym (the non-redirecting backend) for static linked programs to provide it, conditional on _REDIR_TIME64.
* move time_t and suseconds_t definitions to common alltypes.h.inRich Felker2019-11-0217-48/+2
| | | | | | | now that all 32-bit archs have 64-bit time_t (and suseconds_t), the arch-provided _Int64 macro (long or long long, as appropriate) can be used to define them, and arch-specific definitions are no longer needed.
* move time64 ioctl numbers to generic bits/ioctl.hRich Felker2019-11-026-21/+5
| | | | | | | | | | now that all 32-bit archs have 64-bit time types, the values for the time-related ioctls can be shared. the mechanism for this is an arch/generic version of the bits header. archs which don't use the generic header still need to duplicate the definitions. x32, which does not use the new time64 values of the macros, already has its own overrides, so this commit does not affect it.
* move time64 socket options from arch bits to top-level sys/socket.hRich Felker2019-11-0210-45/+11
| | | | | | | | | | now that all 32-bit archs have 64-bit time types, the values for the time-related socket option macros can be treated as universal for 32-bit archs. the sys/socket.h mechanism for this predates arch/generic and is instead in the top-level header. x32, which does not use the new time64 values of the macros, already has its own overrides, so this commit does not affect it.
* switch all existing 32-bit archs to 64-bit time_tRich Felker2019-11-0285-217/+420
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this commit preserves ABI fully for existing interface boundaries between libc and libc consumers (applications or libraries), by retaining existing symbol names for the legacy 32-bit interfaces and redirecting sources compiled against the new headers to alternate symbol names. this does not necessarily, however, preserve the pairwise ABI of libc consumers with one another; where they use time_t-derived types in their interfaces with one another, it may be necessary to synchronize updates with each other. the intent is that ABI resulting from this commit already be stable and permanent, but it will not be officially so until a release is made. changes to some header-defined types that do not play any role in the ABI between libc and its consumers may still be subject to change. mechanically, the changes made by this commit for each 32-bit arch are as follows: - _REDIR_TIME64 is defined to activate the symbol redirections in public headers - COMPAT_SRC_DIRS is defined in arch.mak to activate build of ABI compat shims to serve as definitions for the original symbol names - time_t and suseconds_t definitions are changed to long long (64-bit) - IPC_STAT definition is changed to add the IPC_TIME64 bit (0x100), triggering conversion of semid_ds, shmid_ds, and msqid_ds split low/high time bits into new time_t members - structs semid_ds, shmid_ds, msqid_ds, and stat are modified to add new 64-bit time_t/timespec members at the end, maintaining existing layout of other members. - socket options (SO_*) and ioctl (sockios) command macros are redefined to use the kernel's "_NEW" values. in addition, on archs where vdso clock_gettime is used, the VDSO_CGT_SYM macro definition in syscall_arch.h is changed to use a new time64 vdso function if available, and a new VDSO_CGT32_SYM macro is added for use as fallback on kernels lacking time64.
* add x32 bits/ioctl_fix.h defining time-related sockios macrosRich Felker2019-11-021-0/+4
| | | | | | these definitions are copied from generic bits/ioctl.h, so that x32 keeps the "_OLD" versions (which are already time64 on x32) when 32-bit archs switch to 64-bit time_t.
* add back x32 bits/socket.h defining time-related socket optionsRich Felker2019-11-021-0/+5
| | | | | | | | these definitions are merely copied from the top-level sys/socket.h, so there is no functional change at this time. however, the top-level definitions will change to use the time64 "_NEW" versions on 32-bit archs when time_t is switched over to 64-bit. this commit ensures that change will be suppressed on x32.
* move msghdr and cmsghdr out of bits/socket.hRich Felker2019-11-0211-208/+34
| | | | | | | | | | | | | | | these structures can now be defined generically in terms of endianness and long size. previously, the 32-bit archs all shared a common definition from the generic bits header, and each 64-bit arch had to repeat the 64-bit version, with endian conditionals if the arch had variants of each endianness. I would prefer getting rid of the preprocessor conditionals for padding and instead using unnamed bitfield members, like commit 9b2921bea1d5017832e1b45d1fd64220047a9802 did for struct timespec. however, at present sendmsg, recvmsg, and recvmmsg need access to the padding members by name to zero them. this could perhaps be cleaned up in the future.
* fix x32 msghdr struct by removing x32 bits/socket.hRich Felker2019-11-021-16/+0
| | | | | | | | | | | | being that it contains pointers and (from the kernel perspective, which is wrong) size_t members, x32 uses the 32-bit version of the structure, not a half-32-bit, half-64-bit layout like we had here. the x86_64 definition was inadvertently copied when x32 was first added. unlike errors in the opposite direction (missing padding), this error was not easily detected breakage, because the layout of the commonly used initial subset of members still matched. breakage could only be observed in the presence of control messages or flags.
* make time-related socket options overridable by arch bits filesRich Felker2019-11-021-6/+11
| | | | | | | | | | | SO_RCVTIMEO and SO_SNDTIMEO already were, but only in aggregate with SO_DEBUG and all of the other low/traditional options that varied per arch. SO_TIMESTAMP* are newly overridable. the two groups have to be done separately since mips64 and powerpc64 will override the former but not the latter. at some point this should be cleaned up to use bits headers more idiomatically.
* add framework for arch-provided makefile fragments, compat source dirsRich Felker2019-11-021-2/+3
| | | | | | | | the immediate usage case for this is to let 32-bit archs moving to 64-bit time_t via symbol redirection pull in wrapper shims that provide the old symbol names. in the future it may be used for other types of compatibility-only source files that are not relevant to all archs.
* add __dlsym_time64 asm entry point for all legacy-32bit-time_t archsRich Felker2019-11-029-0/+27
|
* add time64 redirect for, and redirecting implementation of, dlsymRich Felker2019-11-022-0/+31
| | | | | | | | | | | if symbols are being redirected to provide the new time64 ABI, dlsym must perform matching redirections; otherwise, it would poke a hole in the magic and return pointers to functions that are not safe to call from a caller using time64 types. rather than duplicating a table of redirections, use the time64 symbols present in libc's symbol table to derive the decision for whether a particular symbol needs to be redirected.
* add time32 ABI compat shims, compat source treeRich Felker2019-11-0264-0/+1039
| | | | | | | | | | | | | | | | | | | these files provide the symbols for the traditional 32-bit time_t ABI on existing 32-bit archs by wrapping the real, internal versions of the corresponding functions, which always work with 64-bit time_t. they are written to be as agnostic as possible to the implementation details of the real functions, so that they can be written once and mostly forgotten, but they are aware of details of the old (and sometimes new) ABI, which is okay since ABI is fixed and cannot change. a new compat tree is added, separate from src, which the Makefile does not see or use now, but which archs will be able to add to the build process. we could also consider moving other things that are compat shims here, like functions which are purely for glibc-ABI-compat, with the goal of making it optional or just cleaning up the main src tree to make the distinction between actual implementation/API files and ABI-compat shims clear.
* make fstatat fill in old time32 stat fields tooRich Felker2019-10-281-0/+16
| | | | | | | | | | | here _REDIR_TIME64 is used as an indication that there's an old ABI, and thereby the old time32 timespec fields of struct stat. keeping struct stat compatible and providing both versions of the timespec fields is done so that ftw/nftw does not need painful compat shims, and (more importantly) so that similar interfaces between pairs of libc consumers (applications/libraries) will be less likely to break when one has been rebuilt for time64 but the other has not.
* disable lfs64 aliases for remapped time64 functionsRich Felker2019-10-286-0/+14
| | | | | | | these functions cannot provide the glibc lfs64-ABI-compatible symbols when time_t differs from what it was in that ABI. instead, the aliases need to be provided by the time32 compat shims or through some other mechanism.
* prepare struct sched_param for change in time_t definitionRich Felker2019-10-281-0/+4
| | | | | | | | | | the time_t members in struct sched_param are just reserved space to preserve size and alignment. when time_t changes to 64-bit on 32-bit archs, this structure should not change. make definition conditional on _REDIR_TIME64 to match the size of the old time_t, which can be assumed to be long if _REDIR_TIME64 is defined.
* add time64 symbol name redirects to public headers, under arch controlRich Felker2019-10-2821-0/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is expected to define, to control redirection of symbol names for interfaces that involve time_t and derived types. this ensures that object files will only be linked to libc interfaces matching the ABI whose headers they were compiled against. along with time32 compat shims, which will be introduced separately, the redirection also makes it possible for a single libc (static or shared) to be used with object files produced with either the old (32-bit time_t) headers or the new ones after 64-bit time_t switchover takes place. mixing of such object files (or shared libraries) in the same program will also be possible, but must be done with care; ABI between libc and a consumer of the libc interfaces is guaranteed to match by the the symbol name redirection, but pairwise ABI between consumers of libc that define interfaces between each other in terms of time_t is not guaranteed to match. this change adds a dependency on an additional "GNU C" feature to the public headers for existing 32-bit archs, which is generally undesirable; however, the feature is one which glibc has depended on for a long time, and thus which any viable alternative compiler is going to need to provide. 64-bit archs are not affected, nor will future 32-bit archs be, regardless of whether they are "new" on the kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or xtensa port). the same applies to newly-added ABIs for existing machine-level archs.
* add missing m68k user.h/procfs.h regset typesRich Felker2019-10-281-0/+5
|
* update case mappings to unicode 12.1.0Rich Felker2019-10-251-85/+92
|
* update ctype data to unicode 12.1.0u_quark2019-10-254-201/+232
|
* overhaul wide character case mapping implementationRich Felker2019-10-252-290/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the existing implementation of case mappings was very small (typically around 1.5k), but unmaintainable, requiring manual addition of new case mappings with each new edition of Unicode. often, it turned out that newly-added case mappings were not easily representable in the existing tightly-constrained table structures, requiring new hacks to be invented and delaying support for new characters. the new implementation added here follows the pattern used for character class membership, with a two-level table allowing Unicode blocks for which no data is needed to be elided. however, rather than single-bit data, each character maps to a one of up to 6 case-mapping rules available to its block, where 6 is floor(cbrt(256)) and allow 3 characters to be represented per byte (vs 8 with bit tables). blocks that would need more than 6 rules designate one as an exception and let lookup pass into a binary search of exceptional cases for the block. the number 6 was chosen empirically; many blocks would be ok with 4 rules (uncased, lower, upper, possible exceptions), some even just with 2, but the latter are rare and fitting 4 characters per byte rather than 3 does not save significant space. moreover, somewhat surprisingly, there are sufficiently many blocks where even 4 rules don't suffice without a lot of exceptions (blocks where some case pairs are laced, others offset) that originally I was looking at supporting variable-width tables, with 1-, 2-, or 3-bit entries, thereby allowing blocks with 8 rules. as implemented in my experiments, that version was significantly larger and involved more memory accesses/cache lines. improvements in size at the expense of some performance might be possible by utilizing iswalpha data or merging the table of case mapping identity with alphabetic identity. these were explored somewhat when the code was first written, and might be worth revisiting in the future.
* add missing case mapping between U+03F3 and U+037FRich Felker2019-10-251-0/+1
| | | | | | somehow this seems to have been overlooked. add it now so that subsequent overhaul of case mapping implementation will not introduce a functional change at the same time.
* fix errno for posix_openpt with no free ptys availableRich Felker2019-10-241-1/+3
| | | | linux fails the open with ENOSPC, but POSIX mandates EAGAIN.
* adjust struct timespec definition to be time64-readyRich Felker2019-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for time64 support on 32-bit archs, the kernel interfaces use a timespec layout padded to match the representation of a pair of 64-bit values, which requires endian-specific padding. use of an ordinary, non-bitfield, named member for the padding is undesirable because, on big endian archs, it would alter the interpretation of traditional (non-designated) initializers of the form {s,ns}, initializing the padding instead of the tv_nsec member. unnamed bitfield members solve this problem by not taking part in initialization, and were the expected solution when the kernel interfaces were designed. however, they also have further advantages which we take advantage of here: positioning of the padding could be controlled by having a preprocessor conditional with separate definitions of struct timespec for little and big endian, but whether padding should appear at all is a function of whether time_t is larger than long. this condition is not something the preprocessor can determine unless we were to define a new macro specifically for that purpose. by using unnamed bitfield members instead of ordinary named members, we can arrange for the size of the padding to collapse to zero when it should not be present, just by using sizeof(time_t) and sizeof(long) in the bitfield width expression, which can be any integer constant expression.
* clock_adjtime: generalize time64 not to assume old struct layout matchRich Felker2019-10-201-11/+46
| | | | | | | | | | | | | commit 2b4fd6f75b4fa66d28cddcf165ad48e8fda486d1 added time64 for this function, but did so with a hidden assumption that the new time64 version of struct timex will be layout-compatible with the old one. however, there is little benefit to doing it that way, and the cost is permanent special-casing of 32-bit archs with 64-bit time_t in the public interface definitions. instead, do a full translation of the structure going in and out. this commit is actually a revision to an earlier uncommited version of the code.
* wait4, getrusage: add time64/x32 variantRich Felker2019-10-192-3/+61
| | | | | | | | | | | | | | | | | | presently the kernel does not actually define time64 versions of these syscalls, and they're not really needed except to represent extreme cpu time usage. however, x32's versions of the syscalls already behave as time64 ones, meaning the functions were broken on x32 if the caller used any part of the rusage result other than ru_utime and ru_stime. commit 7e8171143124f7f510db555dc6f6327a965a3e84 made it possible to fix this by treating x32's syscalls as time64 versions. in the non-time64-syscall case, make the syscall with the rusage destination pointer adjusted so that all members but the timevals line up between the libc and kernel structures. on 64-bit archs, or present 32-bit archs with 32-bit time_t, the timevals will line up too and no further work is needed. for future 32-bit archs with 64-bit time_t, the timevals are copied into place, contingent on time_t being larger than long.
* internally, define time64 rusage syscalls on x32 as the existing onesRich Felker2019-10-191-0/+2
| | | | | | | | | | | | | | | this is analogous to commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47. so far, there are not any actual time64 versions of the rusage syscalls (getrusage and wait4) and might never be. however, the existing x32 ones behave the way time64 versions would if they existed: using 64-bit slots in place of all longs. presently, wait4 and getrusage are broken on x32, storing the timevals correctly but messing up everything else due to the long/kernel-long mismatch. this would be a huge buffer overflow if not for the 16 reserved slots we left long ago, which suffice to prevent 14 double-sized longs from overflowing into unrelated memory. this commit will make it possible to fix them.
* use struct pt_regs * rather than void * for powerpc[64] sigcontext regsRich Felker2019-10-192-2/+2
| | | | | | | | this is to match the kernel and glibc interfaces. here, struct pt_regs is an incomplete type, but that's harmless, and if it's completed by inclusion of another header then members of the struct pointed to by the regs member can be accessed directly without going through a cast or intermediate pointer object.
* fix fpregset_t type on powerpc64Rich Felker2019-10-191-5/+1
| | | | | | | | | | the userspace ucontext API has this as an array rather than a structure. commit 3c59a868956636bc8adafb1b168d090897692532 fixed the corresponding mistake for vrregset_t, namely that the original powerpc64 port used a mix of types from 32-bit powerpc and powerpc64 rather than matching the 64-bit types.
* fix return value of ungetc when argument is outside unsigned char rangeRich Felker2019-10-181-1/+1
| | | | | | | | | | aside from the special value EOF, ungetc is specified to accept and convert values outside the range of unsigned char. conversion takes place automatically as part of assignment when storing into the buffer, but the return value is also required to be the resulting converted value, and this requirement was not satisfied. simplified from patch by Wang Jianjian.
* fix incorrect use of fabs on long double operand in floatscan.cRich Felker2019-10-181-4/+1
| | | | | | | | | | | | | | based on patch by Dan Gohman, who caught this via compiler warnings. analysis by Szabolcs Nagy determined that it's a bug, whereby errno can be set incorrectly for values where the coercion from long double to double causes rounding. it seems likely that floating point status flags may be set incorrectly as a result too. at the same time, clean up use of preprocessor concatenation involving LDBL_MANT_DIG, which spuriously depends on it being a single unadorned decimal integer literal, and instead use the equivalent formulation 2/LDBL_EPSILON. an equivalent change on the printf side was made in commit bff6095d915f3e41206e47ea2a570ecb937ef926.
* move pthread types out of per-arch alltypes.hRich Felker2019-10-1717-128/+8
| | | | | | | | | | | policy has long been that these definitions are purely a function of whether long/pointer is 32- or 64-bit, and that they are not allowed to vary per-arch. move the definition to the shared alltypes.h.in fragment, using integer constant expressions in terms of sizeof to vary the array dimensions appropriately. I'm not sure whether this is more or less ugly than using preprocessor conditionals and two sets of definitions here, but either way is a lot less ugly than repeating the same thing for every arch.
* define LONG_MAX via arch alltypes.h, strip down bits/limits.hRich Felker2019-10-1734-117/+35
| | | | | | | | | | | | | | | | | | | | | LLONG_MAX is uniform for all archs we support and plenty of header and code level logic assumes it is, so it does not make sense for limits.h bits mechanism to pretend it's variable. LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put it in bits. by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving LLONG_MAX out of bits, there are now no plain-C limits that are defined in the bits header, so the bits header only needs to be included in the POSIX or extended profiles. this allows the feature test macro logic to be removed from the bits header, facilitating a long-term goal of getting such logic out of bits. having __LONG_MAX in alltypes.h will allow further generalization of headers. archs without a constant PAGESIZE no longer need bits/limits.h at all.
* make endian.h expose unprefixed macros, functions in standard profileRich Felker2019-10-171-16/+20
| | | | | | | | | the resolution of Austin Group issue #162 adds endian.h as a standard header for future versions of the standard, making it no longer acceptable for some of the functionality to be hidden behind _BSD_SOURCE or _GNU_SOURCE. the definitions of the [lb]etoh{16,32,64} function-like macros are kept conditional since they are alternate names which the standard did not adopt.
* remove use of endian.h from arch reloc.h headers, clean upRich Felker2019-10-179-24/+0
| | | | | | | | | | building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. since reloc.h is only used from src/internal/dynlink.h, it can be assumed that __BYTE_ORDER is exposed. reloc.h is not permitted to be included in other contexts, and generally, like most arch headers, lacks inclusion guards that would allow such usage. the mips64 version mistakenly included such guards; they are removed for consistency.
* remove indirect use of endian.h from public headersRich Felker2019-10-1712-18/+0
| | | | | | | | building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. endian.h should not be used since, in the future, it will expose identifiers that are not in the reserved namespace for the headers which were previously using it.
* move __BYTE_ORDER definition to alltypes.hRich Felker2019-10-1734-69/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-05-08 21:33:47 +0000