the ppoll function has been accepted as a future part of the standard as the outcome of Austin Group tracker issue 1263. at some point it should be exposed unconditionally, but for now, expose it in the default feature profile.
the ppoll function has been accepted as a future part of the standard as the outcome of Austin Group tracker issue 1263. move the source file to reflect this.
this function was overlooked during the time64 transition, probably as a result of not having any time-related types in its application-side interface. however, for archs that lack the traditional poll syscall and have only ppoll, it used timespec as part of its interface with the kernel: the millisecond timeout was converted to a timespec to pass to SYS_ppoll. this is a type/ABI mismatch on 32-bit archs with legacy time32 syscalls. only one supported arch, or1k, is affected. all of the others either have SYS_poll, or are 64-bit. rather than using timespec, define a type locally to match what the kernel expects. the condition (SYS_ppoll_time64 == SYS_ppoll), comparable to conditions used elsewhere in timespec-handling code, evaluates true for "natively time64" 32-bit archs including x32, future riscv32, and all future 32-bit archs (via definitions in internal syscall.h). otherwise, the arch is either 64-bit or has syscalls that take the legacy type, and in either case "long" is correct. this fix is based on bug report and proposal by Alexey Izbyshev but with a different approach to the changes to minimize the contextual knowledge needed for a reader to understand the source file.
If the (normalized) timeout passed to select exceeds INT_MAX seconds on an arch with SYS_pselect6_time64 and the kernel is too old to support time64 syscalls, the timeout is implicitly converted to (32-bit) long on the fallback path, losing its upper 32 bits and potentially becoming a small positive value, violating the intended semantics, or even a negative value, causing the fallback syscall failure. Fix this by saturating the timeout at INT_MAX as done in other time64 fallback cases.
commit 722a1ae3351a03ab25010dbebd492eced664853b inadvertently passed a
copy of {s,us} to the syscall even if the timeout argument tv was
null, thereby causing immediate timeout (polling) in place of
unlimited timeout. only archs using SYS_select were affected.
major changes are made alongside adding time64 syscall support to account for issues found during research. select historically accepts non-normalized (tv_usec not restricted to less than 1000000) timeouts, and the kernel normalizes them, but the normalization code is buggy and subject to integer overflows. since normalization is needed anyway when using SYS_pselect6 or SYS_pselect6_time64 as the backend, simply do it up-front to eliminate both code path complexity and the possibility of kernel bugs. as a side effect, select no longer updates the caller's timeout timeval with the remaining time. previously, archs that used SYS_select updated it and archs that used SYS_pselect6 didn't. this change may turn out to be controversial and may need revisiting, but in any case the old behavior was not strictly conforming. POSIX allows modification of the timeout "upon successful completion", but the Linux syscall modifies it upon unsuccessful completion (EINTR) as well (and presumably each time the syscall stops and restarts before it's known whether completion will be successful). it's possible that this language does not reflect the actual intent of the standard, since other historical implementations probably behaved like Linux, but that should be clarified if there's a desire to bring the old behavior back. regardless, programs that are depending on this are not correct and are already broken on some archs we support.
time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout length does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there are only superficial changes to the code after preprocessing. both before and after these changes, these functions copied their timeout arguments to avoid letting the kernel clobber the caller's copies. now, the copying also serves to change the type from userspace timespec to a pair of longs, which makes a difference only in the 32-bit fallback case, not on 64-bit.
libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
such archs are expected to omit definitions of the SYS_* macros for syscalls their kernels lack from arch/$ARCH/bits/syscall.h. the preprocessor is then able to select the an appropriate implementation for affected functions. two basic strategies are used on a case-by-case basis: where the old syscalls correspond to deprecated library-level functions, the deprecated functions have been converted to wrappers for the modern function, and the modern function has fallback code (omitted at the preprocessor level on new archs) to make use of the old syscalls if the new syscall fails with ENOSYS. this also improves functionality on older kernels and eliminates the incentive to program with deprecated library-level functions for the sake of compatibility with older kernels. in other situations where the old syscalls correspond to library-level functions which are not deprecated but merely lack some new features, such as the *at functions, the old syscalls are still used on archs which support them. this may change at some point in the future if or when fallback code is added to the new functions to make them usable (possibly with reduced functionality) on old kernels.
this only matters on x32 (and perhaps future 32-on-64 abis for other archs); otherwise the type is long anyway. the cast through uintptr_t prevents nonsensical "sign extension" of pointers, and follows the principle that uintptr_t is the canonical integer type to which pointer conversion is safe.