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
--000000000000639b2805ea75cfe6 Content-Type: text/plain; charset="UTF-8" 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, --000000000000639b2805ea75cfe6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace,monospace"><br></div></div><br><div class=3D"gmail_quote= "><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 7, 2022 at 6:12 AM Alex= ey Dokuchaev <<a href=3D"mailto:danfe@freebsd.org">danfe@freebsd.org</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On F= ri, Sep 30, 2022 at 10:30:52PM +0000, Xin LI wrote:<br> > commit af3c78886fd8d4ca5eebdbe581a459a6f6d29d6a<br> > <br> >=C2=A0 =C2=A0Alter the prototype of qsort_r(3) to match POSIX, which ad= opted the<br> >=C2=A0 =C2=A0glibc-based interface.<br> > <br> >=C2=A0 =C2=A0Unfortunately, the glibc maintainers, despite knowing the = existence<br> >=C2=A0 =C2=A0of the FreeBSD qsort_r(3) interface in 2004 and refused to= add the<br> >=C2=A0 =C2=A0same interface to glibc based on grounds of the lack of st= andardization<br> >=C2=A0 =C2=A0and portability concerns, has decided it was a good idea t= o introduce<br> >=C2=A0 =C2=A0their own qsort_r(3) interface in 2007 as a GNU extension = with a<br> >=C2=A0 =C2=A0slightly different and incompatible interface.<br> > <br> >=C2=A0 =C2=A0With the adoption of their interface as POSIX standard, le= t's switch<br> >=C2=A0 =C2=A0to the same prototype, there is no need to remain incompat= ible.<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).=C2=A0 Can you elaborate on technical side= of<br> things a bit?=C2=A0 Is GNU qsort_r(3) interface, while incompatible, better= <br></blockquote><div><br></div><div><div class=3D"gmail_default" style=3D"= font-family:monospace,monospace">They only have to parenthesize when they a= re utilizing C language features to accomplish a special goal (e.g. to dete= ct if the prototype matches exactly in a configure script) which have a bet= ter alternative (by enabling strict type checks), or are doing something wr= ong (e.g. not including the correct header file).</div></div><div class=3D"= gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cla= ss=3D"gmail_default" style=3D"font-family:monospace,monospace">No normal us= ages of qsort_r(3) required parenthesize, unless they are already broken.</= div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"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?=C2=A0 Thanks,<br></blockquote><div><br></div><div class=3D= "gmail_default" style=3D"font-family:monospace,monospace">It's already = explained in the commit message.</div><div class=3D"gmail_default" style=3D= "font-family:monospace,monospace"><br></div><div class=3D"gmail_default" st= yle=3D"font-family:monospace,monospace">Cheers,<br></div></div></div> --000000000000639b2805ea75cfe6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3sFJuNO3ebEGOsuOqruTMV9AUGrKZeEjBr%2Bu=vUbLjd8Q>