Date: Fri, 7 Oct 2022 11:16:22 -0700 From: Xin LI <delphij@gmail.com> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: Xin LI <delphij@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: af3c78886fd8 - main - Alter the prototype of qsort_r(3) to match POSIX, which adopted the glibc-based interface. Message-ID: <CAGMYy3sFJuNO3ebEGOsuOqruTMV9AUGrKZeEjBr%2Bu=vUbLjd8Q@mail.gmail.com> In-Reply-To: <Y0AlrfmliBbu/t73@FreeBSD.org> References: <202209302230.28UMUq4I029171@gitrepo.freebsd.org> <Y0AlrfmliBbu/t73@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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, [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 7, 2022 at 6:12 AM Alexey Dokuchaev <<a href="mailto:danfe@freebsd.org">danfe@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 30, 2022 at 10:30:52PM +0000, Xin LI wrote:<br> > commit af3c78886fd8d4ca5eebdbe581a459a6f6d29d6a<br> > <br> > Alter the prototype of qsort_r(3) to match POSIX, which adopted the<br> > glibc-based interface.<br> > <br> > Unfortunately, the glibc maintainers, despite knowing the existence<br> > of the FreeBSD qsort_r(3) interface in 2004 and refused to add the<br> > same interface to glibc based on grounds of the lack of standardization<br> > and portability concerns, has decided it was a good idea to introduce<br> > their own qsort_r(3) interface in 2007 as a GNU extension with a<br> > slightly different and incompatible interface.<br> > <br> > With the adoption of their interface as POSIX standard, let's switch<br> > to the same prototype, there is no need to remain incompatible.<br> <br> What a sad story, and so unfair to FreeBSD as we now have to deal with<br> compatibility hacks (as mandree@ had said, having to parenthesize a<br> function name is an abomination). Can you elaborate on technical side of<br> things a bit? Is GNU qsort_r(3) interface, while incompatible, better<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">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).</div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">No normal usages of qsort_r(3) required parenthesize, unless they are already broken.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> than ours in 1-to-1 comparison, leaving the grief of not going with our<br> older one aside? Thanks,<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">It's already explained in the commit message.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Cheers,<br></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3sFJuNO3ebEGOsuOqruTMV9AUGrKZeEjBr%2Bu=vUbLjd8Q>