https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266227
--- Comment #20 from Xin LI <[email protected]> ---
(In reply to Matthias Andree from comment #19)
> 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.
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 to:
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, the
corresponding variant was used and define HAVE_{GNU,BSD}_QSORT_R accordingly.
And change the code to use the HAVE_{GNU,BSD}_QSORT_R definition.
> Besides that, the qsort_r standardization attempt is ill-advised. C11 already
> 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 one,
> and rather than standardizing on an implementation that is behind, they bless
> qsort_r()? Wow.
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?view=msvc-170)
is also slightly, but incompatibly different from C11 qsort_s. We have adopted
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 switch
> 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. The
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 benefit us
more in long term.
--
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.