Re: [PATCH 1/8] gdbsupport: Provide global operators |=, &=, and ^= for enum bit flags

Pedro Alves
2020-08-21T18:10:25Z

On 8/21/20 4:57 PM, Andrew Burgess wrote:
> * Pedro Alves <pedro@palves.net> [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