Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface.
- Reply: Xin LI : "Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface."
- Reply: Pedro Giffuni : "Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface."
- In reply to: Xin LI : "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: Fri, 07 Oct 2022 13:12:13 UTC
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