https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #18 from DB <db0451 at gmail dot com> --- (In reply to Jonathan Wakely from comment #17) > (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). My doubt ultimately arose from a momentary fail at bitwise arithmetic (thinking 1 | 3 == 4, how embarrassing), but I'm glad it elicited this confirmation! Thanks.