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.