This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] Fix sorting of enum values in FlagEnumerationPrinter
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 19 Jan 2016 11:41:42 -0500
- Subject: Re: [PATCH 1/2] Fix sorting of enum values in FlagEnumerationPrinter
- Authentication-results: sourceware.org; auth=none
- References: <1453177390-13881-1-git-send-email-simon dot marchi at polymtl dot ca> <569E17C5 dot 6080909 at redhat dot com>
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.