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 2022-03-27T22:59:15Z psykose alice@ayaya.dev 2022-03-02T20:16:54Z urn:sha1:01b14242cccb03c411d3eb1437c99da663c95507 the change to support passing null was rejected in the past on the grounds that GNU gettext documented it as undefined, on an assumption that only glibc accepted it and that the standalone GNU gettext did not. but it turned out that both explicitly accept it. in light of this, since some software assumes null can be passed safely, allow it. 2022-03-16T23:29:38Z Isaiah Poston isaiah@ilposton.com 2022-03-13T00:21:56Z urn:sha1:6d8a515796270eb6cec8a278cb353a078a10f09a newlocale and freelocale use __libc_malloc and __libc_free, but duplocale used malloc. If malloc was replaced, this resulted in invalid free using the wrong allocator when passing the result of duplocale to freelocale. Instead, use libc-internal malloc for duplocale. This bug was introduced by commit 1e4204d522670a1d8b8ab85f1cfefa960547e8af. 2021-12-09T20:35:13Z Rich Felker dalias@aerifal.cx 2021-12-09T20:35:13Z urn:sha1:8d404733e1314ef633aa09a90865e94fe711b4ca strtod_l, strtof_l, and strtold_l originally existed only as glibc-ABI-compat symbols. as noted in the commit which added them, 17a60f9d327c6f8b5707a06f9497d846e75c01f2, making them aliases for the non-_l functions was a hack and not appropriate if they ever became public API. unfortunately, commit 35eb1a1a9b97577e113240cd65bf9fc44b8df030 did make them public without undoing the hack. fix that now by moving the the _l functions to their own file as wrappers that just throw away the locale_t argument. 2020-12-09T22:11:05Z Rich Felker dalias@aerifal.cx 2020-12-09T22:11:05Z urn:sha1:1e4204d522670a1d8b8ab85f1cfefa960547e8af this is necessary for MT-fork correctness now that the code runs under locale lock. it would not be hard to avoid, but __get_locale is already using libc-internal malloc anyway. this can be reconsidered during locale overhaul later if needed. 2020-12-09T22:01:57Z Rich Felker dalias@aerifal.cx 2020-12-09T22:01:57Z urn:sha1:36246b347cd135399bc79f9b6617d9a120c00a0d in general, pthread_once is not compatible with MT-fork constraints (commit 167390f05564e0a4d3fcb4329377fd7743267560). here it actually no longer matters, because it's now called with a lock held, but since the lock is held it's pointless to use pthread_once. 2020-12-09T21:58:32Z Rich Felker dalias@aerifal.cx 2020-12-09T21:58:32Z urn:sha1:37fcc13c12ade19c37a1a8ac80be4a14e21cff1e this allows the lock to be shared with setlocale, eliminates repeated per-category lock/unlock in newlocale, and will allow the use of pthread_once in newlocale to be dropped (to be done separately). 2020-11-11T20:55:30Z Rich Felker dalias@aerifal.cx 2020-11-11T18:37:33Z urn:sha1:167390f05564e0a4d3fcb4329377fd7743267560 as the outcome of Austin Group tracker issue #62, future editions of POSIX have dropped the requirement that fork be AS-safe. this allows but does not require implementations to synchronize fork with internal locks and give forked children of multithreaded parents a partly or fully unrestricted execution environment where they can continue to use the standard library (per POSIX, they can only portably use AS-safe functions). up until recently, taking this allowance did not seem desirable. however, commit 8ed2bd8bfcb4ea6448afb55a941f4b5b2b0398c0 exposed the extent to which applications and libraries are depending on the ability to use malloc and other non-AS-safe interfaces in MT-forked children, by converting latent very-low-probability catastrophic state corruption into predictable deadlock. dealing with the fallout has been a huge burden for users/distros. while it looks like most of the non-portable usage in applications could be fixed given sufficient effort, at least some of it seems to occur in language runtimes which are exposing the ability to run unrestricted code in the child as part of the contract with the programmer. any attempt at fixing such contracts is not just a technical problem but a social one, and is probably not tractable. this patch extends the fork function to take locks for all libc singletons in the parent, and release or reset those locks in the child, so that when the underlying fork operation takes place, the state protected by these locks is consistent and ready for the child to use. locking is skipped in the case where the parent is single-threaded so as not to interfere with legacy AS-safety property of fork in single-threaded programs. lock order is mostly arbitrary, but the malloc locks (including bump allocator in case it's used) must be taken after the locks on any subsystems that might use malloc, and non-AS-safe locks cannot be taken while the thread list lock is held, imposing a requirement that it be taken last. 2020-11-11T18:31:50Z Rich Felker dalias@aerifal.cx 2020-11-11T18:08:42Z urn:sha1:34952fe5de44a833370cbe87b63fb8eec61466d7 this change lifts undocumented restrictions on calls by replacement mallocs to libc functions that might take these locks, and sets the stage for lifting restrictions on the child execution environment after multithreaded fork. care is taken to #define macros to replace all four functions (malloc, calloc, realloc, free) even if not all of them will be used, using an undefined symbol name for the ones intended not to be used so that any inadvertent future use will be caught at compile time rather than directed to the wrong implementation. 2020-08-22T17:51:32Z Rich Felker dalias@aerifal.cx 2020-08-22T17:51:32Z urn:sha1:9d4b25b4738dbabf628055601d96ba0609c2b4a8 all path elements but the last had the final byte truncated.