https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479
--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to DB from comment #10) > 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 write your own "verify()" function that works like assert() but it will still be there in release mode. I think gnulib has something like that. The important bit is that it is declared noreturn. > 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. For example, if you add a check that the enum is inside its range, the compiler with -fstrict-enums has every right to delete it, even if the enum is actually outside its range (due to a bug). And the compiler may not warn because it may not be able to prove that it is used outside its range at the point it gives the warning. Things only become more complex and unpredictable if each enum can be behave differently.
