When an option that requires an argument is the last character of argv[argc-1], getopt computes argv[argc] + optpos. While optpos is always zero in this case, adding it to null pointer is still undefined.
If lstat/stat fails with EACCES, st is left uninitialized, but its st_dev/st_ino fields are then used in several places: * for FTW_MOUNT check (in practice typically results in a false positive and an early return) * for copying to the new struct history (though the struct is not used afterwards since we don't recurse in this case) * for cycle detection check (could theoretically result in a false positive and an early return) To avoid adding FTW_NS checks to all these places, fix this by zero-initializing st_dev/st_ino (which can never match an existing dentry due to zero inode being reserved in Linux), and check for FTW_NS only when handling FTW_MOUNT since we need two valid dentries there.
originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed.
commit 05973dc3bbc1aca9b3c8347de6879ed72147ab3b made it so that lines longer than INT_MAX can in theory be read, but did not use a suitable type for the positions determined by sscanf. we could change to using size_t, but since the signature for getmntent_r does not admit lines longer than INT_MAX, it does not make sense to support them in the legacy thread-unsafe form either -- the principle here is that there should not be an incentive to use the unsafe function to get added functionality.
According to fstab(5), the last two fields are optional, but this wasn't accepted. After this change, only the first field is required, which matches glibc's behaviour. Using sscanf as before, it would have been impossible to differentiate between 0 fields and 4 fields, because sscanf would have returned 0 in both cases due to the use of assignment suppression and %n for the string fields (which is important to avoid copying any strings). So instead, before calling sscanf, initialize every string to the empty string, and then we can check which strings are empty afterwards to know how many fields were matched.
riscv32 and future architectures only provide prlimit64.
the snd_pcm_mmap_control struct used with SNDRV_PCM_IOCTL_SYNC_PTR was mistakenly defined in the kernel uapi with "before u32" padding both before and after the first u32 member. our conversion between the modern struct and the legacy time32 struct was written without awareness of that mistake, and assumed the time64 version of the struct was the intended form with padding to match the layout on 64-bit archs. as a result, the struct was not converted correctly when running on old kernels, with audio glitches as the likely result. this was discovered thanks to a related bug in the kernel, whereby 32-bit userspace running on a 64-bit kernel also suffered from the types mismatching. the mistaken layout is now the ABI and can't be changed -- or at least making a new ioctl to change it would just result in a worse situation. our conversion here is changed to treat the snd_pcm_mmap_control substruct as two separate substructs at locations dependent on endianness (since the displacement depends on endianness), using the existing conversion framework.
commit 2412638bb39eb799b2600393bbd71cca8ae96bb2 got the size of struct v4l2_event wrong and failed to account for the fact that the old struct might be either 120 bytes with time misaligned mod 8, or 128 bytes with time aligned mod 8, due to the contained union having 64-bit members whose alignment is arch-dependent. rather than adding new logic to handle the differences, use an actual stripped-down version of the structure in question to derive the ioctl number, size, and offsets.
commit 2412638bb39eb799b2600393bbd71cca8ae96bb2 got the size of struct v4l2_buffer wrong and omitted the tv_usec member slot from the offset list, so the ioctl numbers never matched and fallback code path was never taken. this caused the affected ioctls to fail with ENOTTY on kernels not new enough to have the native time64 ioctls.
inability to use realpath in chroot/container without procfs access and at early boot prior to mount of /proc has been an ongoing issue, and it turns out realpath was one of the last remaining interfaces that needed procfs for its core functionality. during investigation while reimplementing, it was determined that there were also serious problems with the procfs-based implementation. most seriously it was unsafe on pre-O_PATH kernels, and unlike other places where O_PATH was used, the unsafety was hard or impossible to fix because O_NOFOLLOW can't be used (since the whole purpose was to follow symlinks). the new implementation is a direct one, performing readlink on each path component to resolve it. an explicit stack, as opposed to recursion, is used to represent the remaining components to be processed. the stack starts out holding just the input string, and reading a link pushes the link contents onto the stack. unlike many other implementations, this one does not call getcwd initially for relative pathnames. instead it accumulates initial .. components to be applied to the working directory if the result is still a relative path. this avoids calling getcwd (which may fail) at all when symlink traversal will eventually yield an absolute path. it also doesn't use any form of stat operation; instead it arranges for readlink to tell it when a non-directory is used in a context where a directory is needed. this minimizes the number of syscalls needed, avoids accessing inodes when the directory table suffices, and reduces the amount of code pulled in for static linking.