From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by sourceware.org (Postfix) with ESMTPS id 288443857026 for ; Fri, 21 Aug 2020 18:10:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 288443857026 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-wr1-f68.google.com with SMTP id p20so2786315wrf.0 for ; Fri, 21 Aug 2020 11:10:25 -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=OIVBZZhnfqAEydHQyjzx6kG7jiMF+E+YXFss3/6OoIs=; b=RSHrsoSS5+OuKSg2/W5afMCCf5G72LGyrgHYSSo1m68L2oQnm0qpifjxpgF3bN368M FK2apAKmRrf+tKHULtkYuwZpkMANRQgVJOyN6LiA0WUnXegltGL6S9IUPqrQduinuZD0 WS0cth18QVk5IM/p/yMrylgJlIkdPSpOJsQR5WxQgSKDwVc0owb13u83VlO8NiYJUH0/ X/KBmMCE3XotB6E2tWPZ0ghAcsayxKmcqaNk2U7kF/IicqR/UpK0Tl7UoIFrtRN5sFWe qV/zs/tCb9Gytaqcp822w35dwYqCd2VULnO9O61/YUyF6sHpkDM3ND6KJsgtjWmFwPut D0uQ== X-Gm-Message-State: AOAM531bF9EHuIKAygXhC0w4JuRMiP/+yg9Lc5q4Xw0a2OXU/unqJ8vO 1Mjglx+ceSbkPx66kziOf13K6o2KBCRh9Q== X-Google-Smtp-Source: ABdhPJxdvTREa+o2hM+0Qqp8+pm+NGclPTPU7s3KiCEkjU5B7tdAhc19bix1FraEbutTBhKcEOmH1Q== X-Received: by 2002:a5d:480b:: with SMTP id l11mr3612083wrq.85.1598033423233; Fri, 21 Aug 2020 11:10:23 -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 b203sm7927581wmc.22.2020.08.21.11.10.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 11:10:22 -0700 (PDT) Subject: Re: [PATCH 1/8] gdbsupport: Provide global operators |=, &=, and ^= for enum bit flags To: Andrew Burgess References: <8eb7f409ca572c526de08ab23878be905f5fef42.1597319264.git.andrew.burgess@embecosm.com> <87a6yvhls1.fsf@tromey.com> <20200817104034.GJ853475@embecosm.com> <89e07f2d-9c33-5f43-d62f-19571ac39c57@palves.net> <20200821155742.GP853475@embecosm.com> Cc: Tom Tromey , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 21 Aug 2020 19:10:21 +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: <20200821155742.GP853475@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 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 18:10:28 -0000 On 8/21/20 4:57 PM, Andrew Burgess wrote: > * Pedro Alves [2020-08-21 15:49:15 +0100]: > >> 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. > > No, I meant 'some_flag'. > Oh, I see now. >> >>> 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. > > I don't understand where 'enum foo_flag_value' came from, so I can't > really respond to this. I mean, this naming: enum foo_flag { .... }; DEF_ENUM_FLAGS_TYPE (foo_flag, foo_flags); could lead to the situation you mentioned more easily than this: enum foo_flag_value { .... }; DEF_ENUM_FLAGS_TYPE (foo_flag_value, foo_flags); As in: DEF_ENUM_FLAGS_TYPE (enum c_string_type_values, c_string_type); DEF_ENUM_FLAGS_TYPE (enum user_selected_what_flag, user_selected_what); DEF_ENUM_FLAGS_TYPE (enum type_instance_flag_value, type_instance_flags); DEF_ENUM_FLAGS_TYPE (enum linux_siginfo_extra_field_values, linux_siginfo_extra_fields); vs: DEF_ENUM_FLAGS_TYPE (enum btrace_insn_flag, btrace_insn_flags); DEF_ENUM_FLAGS_TYPE (enum btrace_function_flag, btrace_function_flags); DEF_ENUM_FLAGS_TYPE (enum btrace_thread_flag, btrace_thread_flags); etc. > >> >>> 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 > > I saw this. Once this gets merged I'll rebase the rest of my series > on top of your work, at which point I assume that this patch will not > be required. I think so. I've now pushed my series to the users/palves/enum-flags-rewrite branch if you ever want to give it a try. I don't plan to push that to master before the branch is cut. Thanks, Pedro Alves