https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to DB from comment #5)
> Of course a malicious and/or absent-minded caller could pass in a value that
> the switch doesn't handle and invoke UB, but what about codebases that don't
> let in such callers? Should they have to artificially add a
> default/return/abort/whatever just to keep their build log readable?
Do you mean codebases with zero bugs and that only omniscient programmers are
allowed to edit and use? ;-)
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.
> So, I feel GCC could do one better by - quite rightly! - defaulting to
> warning about such callers - but, crucially, allowing the warning to be
> disabled by competent ones (willing to take the blame if they pass a duff
> value later)
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)
> But it hits on what I'm going for: ensuring the compiler that I'll only use
> named enumerator values. Ideally though, the Standard or compiler would
> provide a way to specify that as an attribute per enum, so the programmer
> could mix both schemes. I personally haven't used enums as bitmasks, so my
> programs have only used discrete enumerators, but the bitfield case seems
> allowed and common. Still, for cases where I'm not using it, I'd like a way
> to tell the compiler to trust me!
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).
Perhaps I should add an entry to the FAQ summarizing the above (anyone feel
free to beat me to it...)
