[PATCH 1/2] Fix sorting of enum values in FlagEnumerationPrinter
Simon Marchi
simon.marchi@polymtl.ca
Tue Jan 19 16:41:00 GMT 2016
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.
More information about the Gdb-patches
mailing list