Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface.
- Reply: Alexey Dokuchaev : "Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface."
- In reply to: Alexey Dokuchaev : "Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 08 Oct 2022 13:32:57 UTC
Sorry for top-posting ...
Complain here:
https://www.austingroupbugs.net/view.php?id=900
Pedro.
On Friday, October 7, 2022 at 08:12:20 AM GMT-5, Alexey Dokuchaev <danfe@freebsd.org> wrote:
On Fri, Sep 30, 2022 at 10:30:52PM +0000, Xin LI wrote:
> commit af3c78886fd8d4ca5eebdbe581a459a6f6d29d6a
>
> Alter the prototype of qsort_r(3) to match POSIX, which adopted the
> glibc-based interface.
>
> Unfortunately, the glibc maintainers, despite knowing the existence
> of the FreeBSD qsort_r(3) interface in 2004 and refused to add the
> same interface to glibc based on grounds of the lack of standardization
> and portability concerns, has decided it was a good idea to introduce
> their own qsort_r(3) interface in 2007 as a GNU extension with a
> slightly different and incompatible interface.
>
> With the adoption of their interface as POSIX standard, let's switch
> to the same prototype, there is no need to remain incompatible.
What a sad story, and so unfair to FreeBSD as we now have to deal with
compatibility hacks (as mandree@ had said, having to parenthesize a
function name is an abomination). Can you elaborate on technical side of
things a bit? Is GNU qsort_r(3) interface, while incompatible, better
than ours in 1-to-1 comparison, leaving the grief of not going with our
older one aside? Thanks,
./danfe