Date: Tue, 13 Sep 2022 20:24:30 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 266227] [exp-run] Request for exp-run with qsort_r API change Message-ID: <bug-266227-7141-STSZEAHOZt@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-266227-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-266227-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266227 --- Comment #19 from Matthias Andree <mandree@FreeBSD.org> --- (In reply to Xin LI from comment #14) e2fsprogs - I am scratching my head over this, especially over the detection and the "defined qsort_r" part gives me the creeps. It nicely shows the distress to tell one qsort_r interface from another. Besides that, the qsort_r standardization attempt is ill-advised. C11 alrea= dy has qsort_s (but it apparently has not made it into POSIX 2018) and I wonder where GNU libc's implementation is... Fedora 36 apparently does not carry o= ne, and rather than standardizing on an implementation that is behind, they ble= ss qsort_r()? Wow.=20 Do we really need to jump the gun? What are our FreeBSD 14 and the POSIX schedules, will we have all the other things in place when we flip the swit= ch for qsort_r to use the GNU API? I am undecided. Please help me decide, and either propose a better auto-detection (ideally one I can forward upstream) or otherwise convince m= e we are not shooting our feet here. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266227-7141-STSZEAHOZt>