[2/9] Use unsigned as base type for some enums

  On 2018-08-27 04:21 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
> 
> Simon> Can you give an example of how the error manifests itself (I'm not really
> Simon> familiar with -fsanitize=undefined).  Is the error reported at compile-time
> Simon> or run-time?  I'm not able to make a synthetic standalone example to reproduce
> Simon> the error.
> 
> You will get an error at runtime, and with the flags added by the last
> patch in the series, a crash.
> 
> The error looks somewhat like the error from the expression dumping
> patch:
> 
>   runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'
> 
> (I don't have an exact error handy, this was just taken from the other
> patch.)
> 
> Simon> In any case, that LGTM if that makes the compiler happy.  If the error reported
> Simon> by -fsanitize=undefined is at run-time, could we add a static assert in there
> Simon> to make sure the underlying types of types used with DEF_ENUM_FLAGS_TYPE are
> Simon> unsigned, to get a compilation error?
> 
> With the final patch, any UB will cause gdb to crash (in development
> mode), presumably leading to a test suite failure.  I think it isn't
> necessary to require unsigned as the underlying type -- any type will
> do.  However I don't know how to assert that.

Indeed, it's only necessary if the ~ operator is used.  OTOH, it doesn't really
make sense to use a signed type for flags, so we wouldn't lose anything by enforcing
unsigned types.  If I understand correctly, the errors come from code like this, when
making a bit mask to clear some bits:

  btinfo->flags &= ~(BTHR_MOVE | BTHR_STOP);

Doing a static assert like this:



would enforce it at compile time, which is preferable than finding it at
runtime.

Simon
  

On 08/27/2018 10:26 PM, Simon Marchi wrote:
> On 2018-08-27 04:21 PM, Tom Tromey wrote:
>>>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
>>
>> Simon> Can you give an example of how the error manifests itself (I'm not really
>> Simon> familiar with -fsanitize=undefined).  Is the error reported at compile-time
>> Simon> or run-time?  I'm not able to make a synthetic standalone example to reproduce
>> Simon> the error.
>>
>> You will get an error at runtime, and with the flags added by the last
>> patch in the series, a crash.
>>
>> The error looks somewhat like the error from the expression dumping
>> patch:
>>
>>   runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'
>>
>> (I don't have an exact error handy, this was just taken from the other
>> patch.)
>>
>> Simon> In any case, that LGTM if that makes the compiler happy.  If the error reported
>> Simon> by -fsanitize=undefined is at run-time, could we add a static assert in there
>> Simon> to make sure the underlying types of types used with DEF_ENUM_FLAGS_TYPE are
>> Simon> unsigned, to get a compilation error?
>>
>> With the final patch, any UB will cause gdb to crash (in development
>> mode), presumably leading to a test suite failure.  I think it isn't
>> necessary to require unsigned as the underlying type -- any type will
>> do.  However I don't know how to assert that.
> 
> Indeed, it's only necessary if the ~ operator is used.  OTOH, it doesn't really
> make sense to use a signed type for flags, so we wouldn't lose anything by enforcing
> unsigned types.  If I understand correctly, the errors come from code like this, when
> making a bit mask to clear some bits:
> 
>   btinfo->flags &= ~(BTHR_MOVE | BTHR_STOP);
> 
> Doing a static assert like this:
> 
> diff --git a/gdb/common/enum-flags.h b/gdb/common/enum-flags.h
> index 82568a5..c82970c 100644
> --- a/gdb/common/enum-flags.h
> +++ b/gdb/common/enum-flags.h
> @@ -92,6 +92,7 @@ class enum_flags
>  public:
>    typedef E enum_type;
>    typedef typename enum_underlying_type<enum_type>::type underlying_type;
> +  gdb_static_assert (std::is_unsigned<underlying_type>::value);
> 

Yeah.  

I've been meaning to find time to repost by enum-flags v2 fixes,
but, it's never happened...  One of the things that I wanted to
look at is exactly this issue, seeing about coming up with some
solution that is compatible with C++98/C++03, given that the GCC
folks expressed interest in sharing the enum-flags.h header.
Off hand, all I can think of is to introduce a "clear(unsigned mask)"
method that would be used instead of &= and ~...  But maybe really
best is to ignore that (C++98), expecting that GCC will come around
to requiring C++11 in some reasonable timeframe...

>  private:
>    /* Private type used to support initializing flag types with zero:
> 
> 
> would enforce it at compile time, which is preferable than finding it at
> runtime.
Yes, I think that we should add that.

Thanks,
Pedro Alves
  

>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:

Simon> Doing a static assert like this:

Simon> +  gdb_static_assert (std::is_unsigned<underlying_type>::value);

Simon> would enforce it at compile time, which is preferable than finding it at
Simon> runtime.

I made this change.

Tom
  

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

>>>>> "Simon" == Simon Marchi <simon.marchi@ericsson.com> writes:
Simon> Doing a static assert like this:

Simon> +  gdb_static_assert (std::is_unsigned<underlying_type>::value);

Simon> would enforce it at compile time, which is preferable than finding it at
Simon> runtime.

Tom> I made this change.

This change turns out to be a bit too eager.  It requires changing all
the enums that are used by DEF_ENUM_FLAGS_TYPE; including
gcc_qualifiers, which is maintained in gcc (and theoretically at least
is C compatible) -- but operator~ is never actually used with these
other enums, so there isn't any UB to avoid.

However, moving the static assert to operator~ seems to work.

Tom