From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13174 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: qsort_r or qsort_s in musl Date: Mon, 3 Sep 2018 18:53:16 -0400 Message-ID: <20180903225316.GY1878@brightrain.aerifal.cx> References: <20180903205705.GA7639@localhost> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1536015087 14572 195.159.176.226 (3 Sep 2018 22:51:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Sep 2018 22:51:27 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Balazs Kezes Original-X-From: musl-return-13190-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 04 00:51:22 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fwxgo-0003f6-Hf for gllmg-musl@m.gmane.org; Tue, 04 Sep 2018 00:51:22 +0200 Original-Received: (qmail 12256 invoked by uid 550); 3 Sep 2018 22:53:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12236 invoked from network); 3 Sep 2018 22:53:29 -0000 Content-Disposition: inline In-Reply-To: <20180903205705.GA7639@localhost> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13174 Archived-At: On Mon, Sep 03, 2018 at 09:57:05PM +0100, Balazs Kezes wrote: > Hi! > > I can find a lot of discussions on the web around qsort_r and the pain that musl > lacks it but I can't find any official word on this from musl devs. If there is > one, could src/stdlib/qsort.c contain a pointer to it? > > Are there any plans having one of them in musl? I'd prefer qsort_r since that > would provide greater compatibility with glibc. I even found patches for it: > https://gist.github.com/izabera/e68927258ad2d29a1586bad276fabcab > https://github.com/esmil/musl/commit/194f9cf93da8ae62491b7386edf481ea8565ae4e > > qsort_r differs between bsd/osx and glibc though: > https://sourceware.org/ml/libc-alpha/2008-12/msg00003.html > > The argument for qsort_s is that it is in the C11 standard as an optional > feature and has similar interface as glibc's qsort_r. > > To avoid choosing sides it could be even qsort_musl for all I care. I could then > use preprocessor to choose the right version. I know there are many workarounds: > global variables, thread local variables, copy pasting and changing qsort from > musl in my own source tree, using glibc. None of them feel right. > > Any thoughts? I think it's been discussed several times before, probably on the list, but I can summarize the state of the topic as far as I'm aware: qsort_s, as part of Annex K, is pretty much rejected as long as it's neither a mandatory part of C, nor widely used by applications. If we were to implement it, it should conform to the standard function by that name, which would entail doing lots of wrong things like introducing "runtime constraint handler" as global state. It's ironic that the function whose purported purpose is being thread-safe with regard to context ends up introducing mechanisms that make it fundamentally thread-unsafe. qsort_r was at first rejected because of the conflicting definitions -- existence of same-named interfaces with different semantics or signatures is one of the big criteria for exclusion of nonstandard extensions in musl. However, from the FreeBSD side at least there seems to be interest in dropping their version and agreeing upon a standard aligned with glibc's version, for the sake of POSIX: http://austingroupbugs.net/view.php?id=900 I'm not aware of any further progress on the issue, but if it becomes clear that POSIX is either going to standardize a version that agree with the GNU definition, or commit to not standardizing any that conflict, I think the level of consensus we have so far is sufficient to consider doing it. In the mean time, you can always implement a thin wrapper defining qsort_r in terms of qsort, using thread-local storage for the context argument. Rich