This code does not emit a fallthrough warning: int foo(int i) { switch (i) { case 1: i = 0; default: break; } return i; } Basically any case block that falls through to another block of just a break statement does not get a warning. Is this a defect or what was the logic behind this decision?
The warning basically says "you may have forgotten 'break;'". If it falls through to break anyway, what difference does it make if I add a redundant break?
I would close this as invalid.
Isn't this still an implicit fallthrough, though? It may not "be a bug," but that's why warnings are not errors; they may not result in "bugs." The issue is that Clang will warn in this case, so developers get confused about writing compiler-portable code with intentional fallthrough vs being warned about unintentional fallthrough. Why shouldn't developers annotate that the implicit fallthrough from `case 1` to `default` was intentional, making it explicit?
The warning has been carefully designed not to warn in common cases which pose no problems, see e.g. https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7 or the lengthy discussions held around the submission of the feature. Not warning in this case is a very intentional part of those design decisions.
> Not warning in this case is a very intentional part of those design decisions. Can you provide a link to the discussion about this specific case? Is re-evaluating the decision out of the question?
(In reply to Nick Desaulniers from comment #5) > > Not warning in this case is a very intentional part of those design decisions. > > Can you provide a link to the discussion about this specific case? The discussions are on gcc-patches mailing list, look into archives from July 2016 to August or September, initially with -Wswitch-fallthrough in the subject, later -Wimplicit-fallthrough. > Is re-evaluating the decision out of the question? Yes. It is pointless to start warning about code that obviously can't do any harm, it will only alienate users that will need to mark up more code. The work Marek has done on this warning started with getting through warnings on gcc itself and on other projects and has been fine tuned on where it is essential not to warn and where false positives can be acceptable.
What could be useful is to add yet another --extra-strict-fallthrough warning flag that would make it possible for these cases to have a warning.
Useful for what? What exactly is an advantage to require attribute at such a place? Nothing will warn if you put it there, but I don't see a rationale for requiring it.
I came across this issue. Indeed, other compilers (clang, MSVC) warn about this. Now that C and C++ have quasi-standardized the fall-through warnings, it would be great if compilers handled the edge cases consistently. A reading of C23 suggests that a warning is recommended here. The description of the fallthrough attribute (6.7.13.6 in C23) says: """ The use of a fallthrough declaration is intended to suppress a diagnostic that an implementation may otherwise issue for a case or default label that is reachable from another case or default label along some path of execution. """ Note that it talks about whether a case or default label is reachable from another case or default label, but not about whether the reached case or default label does anything of substance. (Of course, this is only a recommendation.)