https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to DB from comment #12)
> (In reply to Jonathan Wakely from comment #11)
> > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > -fstrict-enums tells the compiler it will never have a value outside that
> > range. It does **not** tell it that the type will never have the value 0 or
> > 2.
>
> Huh. So allows non-named values and only enforces min/max, so doesn't
> account for folk doing bitwise ORing?
Huh? I have no idea what you mean by doesn't account for bitwide ORing. The
fact you can have non-named values is essential for bitwide ORing.
enum Bitmask { bit1 = 1, bit2 = 2, bit4 = 4 };
Bitmask b = Bitmask(bit1|bit4);
This creates a value that doesn't correspond to a named enumerator, but
obviously this is valid. (For this type the values of the type are [0,7]
because 7 is the highest value that can be represented in the minimum number of
bits needed to represent all the enumerators).
That's how enumerated types work in C++, although many people seem to
misunderstand them. Enumerations are simply named constants, they don't affect
the type, or codegen, or what the valid values of the type are (except where
the values of the highest and lowest determine the range of valid values).
(In reply to Eric Gallager from comment #15)
> (In reply to Jonathan Wakely from comment #11)
> > (In reply to Eric Gallager from comment #6)
> > > This should probably depend on the -fstrict-enums flag, as that controls
> > > whether enums can have any value or just those values that are enumerated.
> >
> > No, that's not what it does.
> >
> > It tells the compiler the enum will only be one of the values of the
> > enumeration, which is not the same as the values corresponding to
> > enumerators.
> >
>
>
> That's a confusing distinction; they sound like the same thing at first to
> someone like me who doesn't speak standards-ese...
Well ... it's not.
> > As I said in comment 3, the OP's type has the values of int, because it has
> > an underlying type of int.
> >
> > Given enum E { E1 = 1, E3 = 3 } the values of the type are 0, 1, 2 and 3 and
> > -fstrict-enums tells the compiler it will never have a value outside that
> > range. It does **not** tell it that the type will never have the value 0 or
> > 2.
>
>
> Thanks, that example helps clear things up. Could it be added to the
> documentation for -fstrict-enums?
It already says "the values of the enumeration (as defined in the C++ standard;
basically, a value that can be represented in the minimum number of bits needed
to represent all the enumerators)."
The minimum number of bits needed to represent E1 and E3 is two bits, and both
0 and 2 can be represented in two bits.
Can I request that any further discussion happens elsewhere (the gcc-help list
or a general C++ programming forum) because it doesn't belong here.
