Unnamed repository; edit this file 'description' to name the repository. http://euandre.org/git/grovel/atom?h=main 2024-01-05T08:47:09Z 2024-01-05T08:47:09Z EuAndreh eu@euandre.org 2024-01-04T23:36:02Z urn:sha1:8492f115890d56c98c1da24b9fdf26bb1b714c05 2023-11-16T17:55:21Z Rich Felker dalias@aerifal.cx 2023-11-16T17:55:21Z urn:sha1:f314e133929b6379eccc632bef32eaebb66a7335 this matters because the kernel-provided mtab only escapes tabs, spaces, newlines, and backslashes. it leaves carriage returns, form feeds, and vertical tabs literal. 2023-11-16T17:06:17Z q66 q66@chimera-linux.org 2023-11-09T19:48:44Z urn:sha1:ee1d39bc1573c1ae49ee6b658938b56bbef95a6c As entries in mtab are delimited by spaces, whitespace characters are escaped as octal sequences. When reading them out, we have to unescape these sequences to get the proper string. 2023-04-11T13:18:38Z Alexey Izbyshev izbyshev@ispras.ru 2023-03-10T17:00:31Z urn:sha1:6d322159c633050a405b03b927db76b89e402014 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. 2023-04-11T13:18:01Z Alexey Izbyshev izbyshev@ispras.ru 2023-03-10T14:00:50Z urn:sha1:35e9831156efc1b54e1a91917ba0f787d5df3353 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. 2022-10-19T18:01:31Z Rich Felker dalias@aerifal.cx 2022-09-26T21:14:18Z urn:sha1:246f1c811448f37a44b41cd8df8d0ef9736d95f4 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. 2022-05-15T23:26:22Z Rich Felker dalias@aerifal.cx 2022-05-15T23:22:05Z urn:sha1:8974ef2124118e4ed8cad7ee0534b36e5c584c4e 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. 2022-05-15T23:19:42Z Alyssa Ross hi@alyssa.is 2021-09-15T22:11:55Z urn:sha1:751bee0ee727e8d8b003c87cff77ac76f1dbecd6 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. 2022-05-02T03:25:21Z Stefan O'Rear sorear@fastmail.com 2020-09-03T07:31:05Z urn:sha1:41149ea8c7a6f28a1c60478fe7f6b9552aa39e3b riscv32 and future architectures only provide prlimit64. 2021-10-19T20:07:14Z Rich Felker dalias@aerifal.cx 2021-10-19T20:07:14Z urn:sha1:3733c831f293b3bbfd0e51faec8ee71112c62c3e 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.