From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18166 invoked by alias); 24 Aug 2017 06:15:40 -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 125841 invoked by uid 89); 24 Aug 2017 06:15:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=reserved, personal, hear, telling 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, 24 Aug 2017 06:15:20 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EE52EC04B32C; Thu, 24 Aug 2017 06:15:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EE52EC04B32C Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-116-59.phx2.redhat.com [10.3.116.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id B05CF5D9C9; Thu, 24 Aug 2017 06:15:17 +0000 (UTC) Subject: Re: [PATCH 6/6] qsort comparator consistency checking To: Alexander Monakov Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org References: <20170715204749.24398-1-amonakov@ispras.ru> <20170715204749.24398-7-amonakov@ispras.ru> <2504f8b1-d25c-08f0-2d8c-ae65d04070ab@redhat.com> <334ac38c-2f0e-aae0-0144-b19911b909b0@redhat.com> <912f1dfe-cc15-5b67-4edc-6605120dd57d@redhat.com> <20170803155252.GZ2123@tucnak> From: Jeff Law Message-ID: <99cf2025-5d97-d73f-672b-4bafe59fbedc@redhat.com> Date: Thu, 24 Aug 2017 06:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01415.txt.bz2 On 08/10/2017 05:24 AM, Alexander Monakov wrote: > On Wed, 9 Aug 2017, Jeff Law wrote: >>>> The _5th macro isn't that bad either, appart from using reserved namespace >>>> identifiers (it really should be something like qsort_5th and the arguments >>>> shouldn't start with underscores). >>> >>> I didn't understand what Jeff found "ugly" about it; I wonder what epithets >>> would be applied then to more, ahem, unusual parts of GCC. >> I doubt anyone would want to hear what I might say about other code. >> I'm sure I wouldn't want my kids reading how I might refer to certain >> parts of GCC. > > Imho it's no good to just say "ugly" in patch review without any further > elaboration, it only serves to provide a minor chilling effect, telling > the contributor they haven't done good enough (for your personal taste) > without informing them where/how they could have improved. > > More importantly, am I correct in understanding that at this point all > remaining changes are reviewed and approved, and I can go ahead with > preparing vec::qsort -> vec::sort mass-renaming patch and rebasing the > others on top of it? Or is the original approach with argument-counting > trick still under consideration? I still don't like the argument-counting trick. But avoiding it seems even more painful. So let's go with your original approach with the argument-counting trick. At least it's buried and folks likely won't have to look at it with any regularity. jeff