Re: [1/2] PR 78736: New warning -Wenum-conversion

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 1 Sep 2017, Prathamesh Kulkarni wrote:

> > If it's an implicit conversion between different enum types, the warning
> > is correct.  The more important question for the review is: is it correct
> > to replace the implicit conversion by an explicit one?  That is, for each
> > value in the source type, what enumerator of the destination type has the
> > same value, and do the semantics match in whatever way is required for the
> > code in question?
> Well, for instance unit_sign in libgfortran/io.h is defined as:
> typedef enum
> { SIGN_PROCDEFINED, SIGN_SUPPRESS, SIGN_PLUS, SIGN_UNSPECIFIED }
> unit_sign;
> 
> and unit_sign_s is defined:
> typedef enum
> { SIGN_S, SIGN_SS, SIGN_SP }
> unit_sign_s;
> 
> Since the enum types are different, I assume warnings for implicit
> conversion from unit_sign_s to unit_sign would be correct ?
> And since unit_sign_s is a subset of unit_sign in terms of
> value-ranges, I assume replacing implicit by explicit conversion would
> be OK ?

Whether an explicit conversion is OK depends on *the semantics of the 
individual values and the intended semantics of the code doing the 
conversion*.  That is, for the semantics of whatever code converts 
unit_sign_s to unit_sign, is it indeed correct that an input of SIGN_S 
should result in an output of SIGN_PROCDEFINED, an input of SIGN_SS should 
result in an output of SIGN_SUPPRESS and an input of SIGN_SP should result 
in an output of SIGN_PLUS?

That is not a question one should expect C front-end maintainers to have 
any expertise in.  Thus, I strongly advise sending each patch that fixes 
the warning fallout for such conversions separately, CC:ing the 
maintainers of the relevant part of GCC, and including an explanation with 
each such patch of what the semantics are in the relevant code and why an 
explicit conversion is correct.  It would also seem a good idea to me to 
make sure that each enum in question has a comment on its definition, 
saying that the values have to be kept consistent (in whatever way) with 
the values of another enum, because of the conversions in whatever 
function named in the constant, so that people editing either enum know 
they can't just insert values in the middle of it.

-- 
Joseph S. Myers
joseph@codesourcery.com