Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface.

On Fri, Oct 7, 2022 at 6:12 AM 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
>

They only have to parenthesize when they are utilizing C language features
to accomplish a special goal (e.g. to detect if the prototype matches
exactly in a configure script) which have a better alternative (by enabling
strict type checks), or are doing something wrong (e.g. not including the
correct header file).

No normal usages of qsort_r(3) required parenthesize, unless they are
already broken.


> than ours in 1-to-1 comparison, leaving the grief of not going with our
> older one aside?  Thanks,
>

It's already explained in the commit message.

Cheers,