https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #10 from DB <db0451 at gmail dot com> --- (In reply to Manuel López-Ibáñez from comment #8) Thanks for the thoughts! > Those "artificial kludges" not only silence the warning, but also make the > code more readable and help the optimizer. A call to abort() or to any > noreturn function, for example, assert(), will also silence the warning and > it is safer than adding a new option to silence it. Yeah, I've since thought of using abort(), which as you say, silences the warning - and indicates with sufficient strength that this shouldn't happen. assert() isn't much use since the warning would return as soon I compile in release mode... been there, tried that. :) > You can use #pragma GCC diagnostic to disable the warning for this > particular function. If that seems even more of kludge than adding assert(), > you are right. But then, adding a #pragma around your whole codebase (which > is what a new option amounts to) sounds even worse, no?(In reply to DB from > comment #7) Thanks for the hint, and yeah, that would probably produce even messier code ;-) Good to know it exists though. > Perhaps there are uses for an __attribute__((strict_enum)) that can be > attached to particular enums (it would be a more fine-grained version of > -fstrict-enums). However, the effort to implement such a thing and keep it > working seems huge for and the potential fallout for handling it wrong (or > users misusing the attribute). Such an attribute is basically giving even > more license to the compiler to optimize based on undefined behavior, and > users often find UB incomprehensible. Compare that with the effort of > asking users to add __builtin_unreachable() (if they are sure their code > will never be wrong) or add an assert(false) (if they are not completely > sure). Yeah, I think this would be best as a Standard thing, rather than adding another custom attribute to any given compiler. I don't see why it gives "even more licence" to optimise, though, since it'd be conditional per enum, rather than -fstrict-enums, which applies globally... so if anyone inadvertently invokes UB, they've got much more chance of being caught out if they're using the existing global option, than if there was a per-enum attribute for whether or not the value must be a named enumerator. > Perhaps I should add an entry to the FAQ summarizing the above (anyone feel > free to beat me to it...) Couldn't hurt. :) There are some great explanations collected around the net (including some on IRC, but I'm sure you know those ;) but it's hard to find a pre-emptive summary of why this isn't already done. Thanks!
