From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by sourceware.org (Postfix) with ESMTPS id 521F53851C04 for ; Fri, 21 Aug 2020 14:49:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 521F53851C04 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wm1-f68.google.com with SMTP id k20so2098173wmi.5 for ; Fri, 21 Aug 2020 07:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d0Q5HyRUupV23ErxNoPVyYDh/qwr5mXlGXa7JXsj9xs=; b=QDgkzIg12hcN814CHSEnz74VHioozEUfK6H5iOAQq5AMjVG4t69sKfJk6161u9INYg FqacX2Zm8byBfUNFsQlNIcKEDNs0QWApKd22oEKF7E6egXkEym5cifCmN1q+KjUNNi5A TFsV6zC32mFS6/KDJj+nm1029OIIOqUs/YqJGDPHvzXq+L5Fby8pACTMDsTBSvLLqxfU QLlIflB1BWaYLWHmiAqpfTk29vCh1E+eWvfK3RKpDNh0RXAf1dEaeph2AlNC06spKRn8 6NqKAQxBHqSCBm9306Zeh5QuIR1q9gqkaxAYf+FpOiBEtb8RQonKA/sqe5weXsf+hHtt JCyg== X-Gm-Message-State: AOAM533BsMTYkTInfGRqjgmsVsi5pzkvNq8A10JhARO9r/3o5RLkKm61 ABr6FV9Y4hdAC+2qd0vdZNIbcxFPcZbWRg== X-Google-Smtp-Source: ABdhPJwKJ05eqdR9NhY0EjjWaoUKKKSZM3w/0alJHY8T0q4yoblkkSNYS+Ul/9ndQaf8b7W/ZkuHSQ== X-Received: by 2002:a1c:28d5:: with SMTP id o204mr4437317wmo.104.1598021361522; Fri, 21 Aug 2020 07:49:21 -0700 (PDT) Received: from ?IPv6:2001:8a0:f905:5600:56ee:75ff:fe8d:232b? ([2001:8a0:f905:5600:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id x8sm1543524wrq.42.2020.08.21.07.49.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 07:49:20 -0700 (PDT) Subject: Re: [PATCH 1/8] gdbsupport: Provide global operators |=, &=, and ^= for enum bit flags To: Andrew Burgess , Tom Tromey References: <8eb7f409ca572c526de08ab23878be905f5fef42.1597319264.git.andrew.burgess@embecosm.com> <87a6yvhls1.fsf@tromey.com> <20200817104034.GJ853475@embecosm.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <89e07f2d-9c33-5f43-d62f-19571ac39c57@palves.net> Date: Fri, 21 Aug 2020 15:49:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200817104034.GJ853475@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 14:49:24 -0000 On 8/17/20 11:40 AM, Andrew Burgess wrote: > > 3. Instead of writing 'enum some_flag', a developer might just write > 'some_flag'. I suspect you meant 'some_flags' in the latter case. > In this case they still require the changes from my > patch if they ever want to use operator|=. I think spotting the > missing 's' is much harder during review, I'd argue that that's an issue of naming. If people thing it's a problem, we can use a more distinct name for the raw enums. Some cases use enum foo_flag_value / foo_flags, which seems reasonable to me. > so it's easy for uses of > 'some_flag' to creep into the code base, then a future developer > wanting to use 'operator|=' will need to fix up the 'some_flag' to > 'some_flags' miss-match. Though it's easy to argue that the first > developer made a mistake, and we frequently have to fix the mistakes > of those going before, in this case we don't have to, so why force > the matter? > > I guess my argument would be, lets commit. We should either remove > the existing global operators from enum-flags.h, fix up the fall out, > and so make it much harder to developers to use the 'some_flag' > version (so forcing the use of 'some_flags'), or make the change I > propose which allows the full range of operators while loosing non of > the protection that already exists. This (again) reminded me of my enum-flags.h rewrite that I never managed to commit... I spent time around it yesterday/today, and posted it here: https://sourceware.org/pipermail/gdb-patches/2020-August/171392.html Thanks, Pedro Alves