From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42053 invoked by alias); 19 Jan 2016 16:41:48 -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 41605 invoked by uid 89); 19 Jan 2016 16:41:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*UA:Webmail 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, 19 Jan 2016 16:41:44 +0000 Received: by simark.ca (Postfix, from userid 112) id A52D81EB30; Tue, 19 Jan 2016 11:41:42 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 5190C1E042; Tue, 19 Jan 2016 11:41:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 19 Jan 2016 16:41:00 -0000 From: Simon Marchi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] Fix sorting of enum values in FlagEnumerationPrinter In-Reply-To: <569E17C5.6080909@redhat.com> References: <1453177390-13881-1-git-send-email-simon.marchi@polymtl.ca> <569E17C5.6080909@redhat.com> Message-ID: <35bba9e534e14532c11ad7c0a5c1db2b@simark.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.1.3 X-SW-Source: 2016-01/txt/msg00438.txt.bz2 On 2016-01-19 06:02, Pedro Alves wrote: > Thanks for catching this. > > I find it surprising that the printer doesn't respect the > order of the values as they're defined though. Shouldn't we > remove the sort line entirely, thus keeping the > existing behavior? I couldn't find mention of the sorting > in the documentation either. > > Or, maybe the printer doesn't work correctly if the "overlapping" > value (which I think it the whole point of this printer) is defined > before the particular values, like, e.g.: > > enum flag_enum > { > ALL = 1 | 2 | 4, > FLAG_2 = 2, > FLAG_3 = 4, > FLAG_1 = 1, > }; > > ? If we don't sort the values and ALL is defined first, then 0x7 will be displayed as ALL instead of FLAG_1 | FLAG_2 | FLAG_3. I don't think either is wrong, we just don't know which one each particular user would prefer. So I think we can choose one way (sorted order, or definition order) and stick with it. Personally, I think I would prefer the more explicit version (FLAG_1 | FLAG_2 | FLAG_3), which means keeping the sort. > On 01/19/2016 04:23 AM, Simon Marchi wrote: > >> + >> enum flag_enum >> { >> - FLAG_1 = 1, >> + /* Define the enumration values in an unsorted manner to verify >> that we >> + effectively sort them by value. */ > > typo: "enumration". Fixed.