https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951
Eric Gallager <egallager at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=81665 --- Comment #18 from Eric Gallager <egallager at gcc dot gnu.org> --- (In reply to Vitali from comment #17) > I was explicitly asked to open this as a separate bug in comment #7 of > 87950. Would be helpful if the GCC devs could coordinate to figure out if > they want separate bugs for C/C++ or 1 bug. > > Jonathan, on this forum your feedback comes off a bit like Skinner where he > blames the children. There's clearly a gap between how compiler authors > define switches as working & how developers wish to use those enums/wish > those enums were actually defined. I appreciate there's a large amount of > legacy code that complicates this issue but I don't think that condescending > to people trying to communicate the issue in good faith moves the > conversation along. > > I'd argue that clang strikes a much better balance here in terms of the > practical implications of the warning even if it's not perfect. In my mind, > warnings are most useful when they optimize for a low rate of false > positives. The GCC warnings for enums do not in practice have a low rate of > false positives and are clearly tuned to minimize false negatives (i.e. > accidentally missing a switch statement that doesn't have all enums > covered). > > At the very least it would be useful to give users the power to turn on a > warning equivalent to Clang's that minimizes false negatives (or change > -Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of > -pedantic for the current behaviour). > > You could even provide annotations that let users annotate enums/switches in > an explicit fashion to indicate that they can be constructed with non-label > values/aren't expected to be depending on which flag you choose to use to > silence warnings/let the compiler optimize more fully. > > In practice, definitely in C++, enums ARE intended to be a closed set of all > possible paths & the flags/random integer value cases are far less > frequently used; even for bitmasks it's a lazy way to do it. In C++ I > usually define strongly-typed types that represent the bitmask & overload > the bit math operators for the enum to yield that secondary type. I think > considering that's a technique used by Boost & Qt, it's reasonable to assume > that having the enum double as the storage type for the bitmask is more of a > hack technically allowed than one that is considered best practice by large > C++ projects. In C it's more muddled because there's no operator > overloading, but the number of enums that exist far outnumber the uses where > it's used for bitwise math. This reminded me of bug 81665