From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4979 invoked from network); 8 Aug 2021 23:05:56 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Aug 2021 23:05:56 -0000 Received: (qmail 27963 invoked by uid 550); 8 Aug 2021 23:05:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27941 invoked from network); 8 Aug 2021 23:05:53 -0000 Date: Sun, 8 Aug 2021 19:05:36 -0400 From: Rich Felker To: Jon Chesterfield Cc: musl@lists.openwall.com, Olivier Galibert Message-ID: <20210808230535.GY13220@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] stdlib: implement qsort_r On Sun, Aug 08, 2021 at 10:21:06PM +0100, Jon Chesterfield wrote: > On Sun, Aug 8, 2021 at 9:39 PM Érico Nogueira wrote: > > > This is the favored approach, from what I understood of the discussions > > surrounding it. It's implemented with musl's namespacing rules and such > > in [1]. > > > > Unsurprisingly I like your patch. > > > > > It is badly optimized for some archs, unfortunately, as explained in the > > thread from [2]. I believe that's what's holding it up. > > > > [1] > > https://inbox.vuxu.org/musl/20210309210213.29539-1-ericonr@disroot.org/ > > [2] > > https://inbox.vuxu.org/musl/20210309150320.GU32655@brightrain.aerifal.cx/ > > > And that's what I get for not reading the list carefully enough. I missed > the thread > from March entirely. No problem. Indeed, this was stalled because of concerns about bad compiler behavior on some archs, but I really don't want to allow that to dictate how we solve the problem. The compiler is doing the wrong thing (failing to tail call) and should just be fixed. I'll probably merge the tail-call patch as-is, or with any minimal fixes needed, right after this release so as not to make major API changes at last minute. Rich