Date: Tue, 13 Sep 2022 21:45:59 +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-v8hty5LOaR@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 #20 from Xin LI <delphij@FreeBSD.org> --- (In reply to Matthias Andree from comment #19) > e2fsprogs - I am scratching my head over this, especially over the detect= ion=20 > and the "defined qsort_r" part gives me the creeps. It nicely shows the=20 > distress to tell one qsort_r interface from another. I agree. This is meant to be a stop-gap solution: once the change of qsort= _r landed, we will have a new __FreeBSD_version which can be used for the detection. Another potentially better solution would be to have the configure script t= o: 1. Detect if there is a qsort_r, and 2. When it does, have two C programs with "#include <stdlib.h>" followed by= BSD and GNU definition signatures, and compile; if the compilation succeeded, t= he corresponding variant was used and define HAVE_{GNU,BSD}_QSORT_R accordingl= y. And change the code to use the HAVE_{GNU,BSD}_QSORT_R definition. > Besides that, the qsort_r standardization attempt is ill-advised. C11 alr= eady > has qsort_s (but it apparently has not made it into POSIX 2018) and I won= der > where GNU libc's implementation is... Fedora 36 apparently does not carry= one, > and rather than standardizing on an implementation that is behind, they b= less > qsort_r()? Wow.=20 Well, the crazy part of qsort_s is that the Microsoft version (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/qsort-s?v= iew=3Dmsvc-170) is also slightly, but incompatibly different from C11 qsort_s. We have ado= pted the C11 signature. > 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 sw= itch > for qsort_r to use the GNU API? I think yes. It's clear that the GNU API have been adopted by more software nowadays. T= he problem was created by glibc maintainers, yes, and I don't like their API either, but making software developer's life easier on FreeBSD would benefi= t us more in long term. --=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-v8hty5LOaR>