From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118238 invoked by alias); 18 Feb 2020 20:48:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118215 invoked by uid 89); 18 Feb 2020 20:48:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 20:48:37 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A6FD01E5FA; Tue, 18 Feb 2020 15:48:35 -0500 (EST) Subject: Re: [PATCH 3/5] gdb: allow duplicate enumerators in flag enums To: Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org References: <20200213203035.30157-1-simon.marchi@efficios.com> <20200213203035.30157-3-simon.marchi@efficios.com> <87a75f7hs7.fsf@tromey.com> From: Simon Marchi Message-ID: <31be9c0a-c389-123b-e2cd-338add47aca2@simark.ca> Date: Tue, 18 Feb 2020 20:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87a75f7hs7.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00742.txt.bz2 On 2020-02-18 3:38 p.m., Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> I have come across some uses cases where it would be desirable to treat > Simon> an enum that has duplicate values as a "flag enum". For example, this > Simon> one here [1]: > > Simon> /* Alias for header backward compatibility. */ > Simon> MEMBARRIER_CMD_SHARED = MEMBARRIER_CMD_GLOBAL, > Simon> }; > > Simon> The last enumerator is kept for backwards compatibility. Without this > Simon> patch, this enumeration wouldn't be considered a flag enum, because two > Simon> enumerators collide. With this patch, it would be considered a flag > Simon> enum, and the value 3 would be printed as: > > Does it always choose the first enumerator? Yes. generic_val_print_enum_1 iterates on the enum type's fields (so, enumerators) and clears those bits in the value as it goes. So if multiple enumerators match, the first one in the enum type's fields will be printed. Is this list of fields guaranteed to be in the same order as what's in the code though? > > Simon> if (nbits != 0 && nbits && nbits != 1) > Simon> flag_enum = 0; > Simon> - else if ((mask & value) != 0) > Simon> - flag_enum = 0; > Simon> - else > Simon> - mask |= value; > > I wonder if this allows too much, though. > > Maybe instead it should check for duplicate enumerator values and allow > those, while still disallowing enums with conflicts, like: > > enum x { > one = 0x11, > two = 0x10, > three = 0x01 > }; > > ... which probably isn't a sensible flag enum. Not sure what you mean here. With the current patch, this enum would not bne marked as a flag enum, as `one` has multiple bits set. Simon