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

[Pedro Alves <pedro@palves.net>]

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