From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60354 invoked by alias); 10 May 2018 18:40:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 56617 invoked by uid 89); 10 May 2018 18:40:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=gnulib, re-use, traditionally, imply X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 May 2018 18:40:17 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D412925BBE; Thu, 10 May 2018 18:40:15 +0000 (UTC) Received: from greed.delorie.com (ovpn-121-173.rdu2.redhat.com [10.10.121.173]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 924BA60BEB; Thu, 10 May 2018 18:40:15 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.14.7/8.14.7) with ESMTP id w4AIeDL6019876; Thu, 10 May 2018 14:40:14 -0400 From: DJ Delorie To: Alexander Monakov Cc: richard.guenther@gmail.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 1/2] gcc_qsort: source code changes In-Reply-To: (message from Alexander Monakov on Thu, 10 May 2018 21:07:11 +0300 (MSK)) Date: Thu, 10 May 2018 18:57:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00504.txt.bz2 Alexander Monakov writes: > I'm not sure. It has a weaker contract compared to qsort, and I believe > functions in libiberty are understood to provide stronger/better replacements. The original intent of libiberty was to provide a stronger *portability* contract, i.e. to work around differences in underlying operating systems. The xfoo() variants often handle error conditions also, as that has traditionally been something that OSs do differently anyway. Having said that, adding something to libiberty is more complicated than adding something to gcc (it didn't used to be), and if nobody else needs a more portable qsort, it's a wasted effort. Libiberty is *not* a generic "toss things in here because they're useful and generic" library, despite being used as such. However, it is common among a few large projects (which used to share a repo, limiting copies of libiberty to one), and does help in code re-use. Given all that, I'd say that an xqsort might be appropriate in libiberty, if it was (1) able to take over for the generic qsort[1] , and (2) the changes are also needed or useful in one of the other projects using libiberty. But given that it's currently written in C++ (it would need to be C-compatible) and only used by gcc, IMHO putting it in libiberty would be inappropriate at this time. The fact that qsort is defined to be nondeterministic is not a portability issue[2]. Consider that there is also gnulib, which serves a similar purpose. [1] i.e. if replacing qsort() with xqsort() in a C or C++ program resulted in the same behavior as far as standards imply. [2] if the nondeterminism is a problem, you probably need to fix your compare function ;-)