Date: Sun, 03 Aug 2014 16:06:46 +0100 From: Bruce Simpson <bms@fastmail.net> To: Warner Losh <imp@bsdimp.com>, Pedro Giffuni <pfg@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r268943 - in head: include lib/libc/stdlib Message-ID: <53DE5006.6000601@fastmail.net> In-Reply-To: <65378493-7F05-4314-9809-E689891F6067@gmail.com> References: <201407211522.s6LFMnQo084633@svn.freebsd.org> <53CD430F.5040604@fastmail.net> <68E8EDB9-64DE-4037-9047-C8BEAD86801A@freebsd.org> <65378493-7F05-4314-9809-E689891F6067@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/08/2014 15:27, Warner Losh wrote: >>> What, if anything, can be done about qsort_r() API incompatibility? >> qsort_r is non-standard and we did it first, plus we will want to stay compatible with Apple :). >> >> I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE >> is defined, but I won’t volunteer to do that. > Are there any ABI considerations for the change? > I'm in agreement with Pedro here. Some form of compile-time checking is the best one can hope for in that situation, as it would be difficult to "ret-con" the qsort_r() ABI itself. The glibc implementation swaps two pointers in its signature. One of those points to executable code. The last time this caused problems for me was when testing the new CScope indexing backend by Elad Lahav on BSD/Mac. He had developed on Linux, however the quick fix was to fall back to using non-reentrant qsort().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53DE5006.6000601>