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
jos...@codesourcery.com
