FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.4 2025-12-03T02:34:33Z 2025-12-03T02:34:33Z Jose Luis Duran jlduran@FreeBSD.org 2025-11-26T20:34:56Z urn:sha1:1869d604e22d88c8c7487cd8a547de42847a40be If the locale's positive_sign and negative_sign values would both be returned by localeconv() as empty strings, strfmon() shall behave as if the negative_sign value was the string "-". This occurs with the C locale. The implementation previously assigned "0" to sign_posn (parentheses around the entire string); now it assigns it to "1" (sign before the string) when it is undefined (CHAR_MAX). Austin Group Defect 1199[1] is applied, changing the requirements for the '+' and '(' flags. [1]: https://www.austingroupbugs.net/view.php?id=1199 Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53913 (cherry picked from commit cf85e7034ad5640b18a3b68d6b291b7bf89bfc80) 2025-12-03T02:34:21Z Jose Luis Duran jlduran@FreeBSD.org 2025-11-26T20:34:55Z urn:sha1:8dc8e3011d05bdadb3e62fe99fbb054e33bfd8f2 According to the Open Group Base Specifications Issue 8[1], strfmon(3) should return EINVAL when the '+' flag was included in a conversion specification and the locale's positive_sign and negative_sign values would both be returned by localeconv(3) as empty strings. Austin Group Defect 1199[2] is applied, adding the [EINVAL] error. [1]: https://pubs.opengroup.org/onlinepubs/9799919799/functions/strfmon.html [2]: https://www.austingroupbugs.net/view.php?id=1199 Reviewed by: kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D53912 (cherry picked from commit 1fd018972a18b682521bb8f004dfd162327e5db2) 2025-12-03T02:33:57Z Jose Luis Duran jlduran@FreeBSD.org 2025-11-23T16:58:55Z urn:sha1:f830e53fc0850e58790ee8c58552a9f049244fd4 MFC after: 1 week (cherry picked from commit 91e7f19ec4056587a85c1461a4f34a6d5d4b7b52) 2025-11-22T09:19:59Z Gordon Bergling gbe@FreeBSD.org 2025-11-19T14:17:40Z urn:sha1:9437a4d37e57b3d986af25379b2e171c25564b0e - s/avaliable/available/ (cherry picked from commit 9334fa3ef5e19de7d3dcdbefdaa3f6b6b653475a) 2025-10-20T16:11:34Z Dag-Erling Smørgrav des@FreeBSD.org 2025-10-13T11:53:31Z urn:sha1:4ab2e9d4feec969a634f26924822da94efabab7c We've been mostly POSIX-conforming since r236400 and fully since r240410, which fixed a corner case where a missing non-leaf directory would be reported as ENOTDIR instead of ENOENT. Sponsored by: Klara, Inc. Fixes: 7877ed7ce33e ("Avoid mapping ENOENT to ENOTDIR for non-existent path components.") Reviewed by: ziaee, markj Differential Revision: https://reviews.freebsd.org/D53027 (cherry picked from commit 7c66667d45e95af59f59e41ef169119a974a6be1) 2025-10-20T16:11:34Z Dag-Erling Smørgrav des@FreeBSD.org 2025-10-13T11:53:22Z urn:sha1:bebae0e231290833b04935e4c18e25931e766587 If lstat() fails with EACCES or ENOTDIR, the path we need to return in the caller-provided buffer is that of the parent directory (which is either unreadable or not a directory; the latter can only happen in the case of a race) rather than that of the child we attempted to stat. Sponsored by: Klara, Inc. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D53025 (cherry picked from commit 1406de21e176d8700240ac9e473df007cd41eec1) 2025-08-27T18:49:58Z Dag-Erling Smørgrav des@FreeBSD.org 2025-08-15T07:22:33Z urn:sha1:f1e93df44ba0b494c6eda01958a71fec501bc32b As pointed out in the PR and the article linked below, the switch to insertion sort in the BSD qsort code is based on a misunderstanding of Knuth's TAOCP and is actually a pessimization. As demonstrated by the added test, it is trivially easy to construct pathological input which results in quadratic runtime. Without that misguided optimization, the same input runs in nearly linearithmic time. https://www.raygard.net/2022/02/26/Re-engineering-a-qsort-part-3 PR: 287089 MFC after: 1 week Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D51907 (cherry picked from commit 5205b32de3fb7702e96b3991f5b1a61eee406d8b) 2025-04-17T01:01:36Z Aurélien Croc de Suray freebsd@ap2c.com 2025-04-05T00:47:53Z urn:sha1:c43ae65b4b89be422cdcd399a7abc44f6db4b298 science/dlib-cpp reveals an interesting scenario that works fine on other platforms but not on FreeBSD; notably, it ends up creating a new global object from some destructor which is called during __cxa_finalize. This breaks when libdlib is dlopen()ed and then subsequently dlclose()ed, as we never end up invoking the created object's dtor until program exit when the shlib is already unmapped. Fix it by noting when we're in the middle of __cxa_finalize for a dso, and then restarting the search if __cxa_atexit() was called in the middle somewhere. We wait until we've processed the initial set before starting over and processing the newly added handlers as if it were a complete set of handlers added during runtime. The alternative is calling them as they're added to maintain a LIFO in terms of total ordering, but in theory a constructor could add another global object that also needs to be destroyed, and that object needs to be destroyed after the one that constructed it to avoid creating unexpected lifetime issues. This manifests in the pdlib PHP extension for dlib crashing, see [0]. [0] https://github.com/goodspb/pdlib/issues/39 PR: 285870 Reviewed by: kevans (also supplied commit message) (cherry picked from commit 23427c8e1fedb9fc68ad0bd27a59c7ffd2b3008c) 2024-12-22T07:30:52Z Xin LI delphij@FreeBSD.org 2024-10-28T06:15:21Z urn:sha1:97cf82ebe02210daf14801f40164adc98e5197f4 Reviewed by: emaste, trasz Differential Revision: https://reviews.freebsd.org/D47262 (cherry picked from commit 3df1abdfd9c309efbdc7884d6b6f6fe25efcb397) 2024-11-21T00:45:07Z Ed Maste emaste@FreeBSD.org 2024-11-14T19:30:54Z urn:sha1:098ed26bf4564362c4478b8c92b11ab9ca074da1 Reviewed by: brooks, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D47581 (cherry picked from commit dfa0ac74c2fbc1cde3e8cdb1ab9fe5cbb90a9b16)