From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-455586-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 87313 invoked by alias); 9 Jun 2017 20:07:55 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 87303 invoked by uid 89); 9 Jun 2017 20:07:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=tired
X-HELO: mail-io0-f172.google.com
Received: from mail-io0-f172.google.com (HELO mail-io0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 20:07:53 +0000
Received: by mail-io0-f172.google.com with SMTP id y77so37539940ioe.3        for <gcc-patches@gcc.gnu.org>; Fri, 09 Jun 2017 13:07:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:mime-version:in-reply-to:references:from:date         :message-id:subject:to:cc;        bh=6J9F94NNTH7AkxmzCkTHSa5mOeH0g3GVMFFBLLGhlTU=;        b=nJGg6esVUNVLNS49K0sfgAMW9ejJCCbX8b1iLW16tfZjFTwsmx1s3WoxzKYWoxS8lK         NnwU9gWrXlaibJOvRO55gFxIvfS0E8X/ltrTMIZlWmEIaPU3NAbzwVpT/hHXjLBdW9qs         Z4SS0ecjdMKSslNkCbilhtIWc3InnZo+1YAzMGQBNxaMaPX+exumfBA1D8I/yeW2JgFz         xpvNIncFMGPLvqg8vSDrHQFvKZZ80SSns4eFgvXMbjNTNgyjCfn0bQIL3WGS8rLtJC2P         RqfCa4GfQAAoc2gDxiAY3l+a/w4Nt3+bElSFUv1x7YIum1t3i4rigtLGYindQfkQkYOu         rUnA==
X-Gm-Message-State: AKS2vOyMUHXBOiPtA3nRip5NChj2yC+EiYybKdpJn6WSkH//LtmRuRry	nB6dnGAtU61fINJUkcDCP4fkA1I4snNr
X-Received: by 10.107.5.76 with SMTP id 73mr2109750iof.182.1497038876614; Fri, 09 Jun 2017 13:07:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.20.139 with HTTP; Fri, 9 Jun 2017 13:07:36 -0700 (PDT)
In-Reply-To: <CADzB+2nTdYJ9+jqdTpRdPynar3RG9CmFu3Go2fQnnmm808-ALA@mail.gmail.com>
References: <CADzB+2=nUE9Ma58PpzfaC97+TxXd3bBJ3Er_ZeAQjXogfUsEcw@mail.gmail.com> <b9644643-c164-bc33-4818-f2b2e7f1b892@gmail.com> <CADzB+2nTdYJ9+jqdTpRdPynar3RG9CmFu3Go2fQnnmm808-ALA@mail.gmail.com>
From: Jason Merrill <jason@redhat.com>
Date: Fri, 09 Jun 2017 20:07:00 -0000
Message-ID: <CADzB+2=U2XdJPX62Qso+1G3z7fqmFJZ-yuS-qOZv9vT59V9=eA@mail.gmail.com>
Subject: Re: RFA: PATCH to add id_strcmp helper function
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches List <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2017-06/txt/msg00681.txt.bz2

On Tue, May 23, 2017 at 5:52 PM, Jason Merrill <jason@redhat.com> wrote:
> On Thu, May 18, 2017 at 11:03 PM, Martin Sebor <msebor@gmail.com> wrote:
>> On 05/18/2017 08:30 PM, Jason Merrill wrote:
>>>
>>> I got tired of writing strcmp (IDENTIFIER_POINTER and decided to wrap
>>> it in an inline function.  I decided to use "id_strcmp" instead of
>>> just overloading strcmp, but I don't feel strongly about that choice.
>>>
>>> The second patch changes all existing uses of that pattern to use the
>>> new function.
>>>
>>> OK for trunk?
>>
>>
>> Since all the uses are of the form !id_strcmp(), would taking
>> a step further and introducing a bool id_equal() be going too
>> far?
>>
>> Besides being (arguably) easier to read, it would get around
>> the question of whether it should be !id_strcmp() or
>> id_strcmp == 0, or perhaps even 0 == id_strcmp().
>
> Makes sense.
>
> OK for trunk?

Ping?