On 07/27/2016 11:59 AM, Marek Polacek wrote:
On Wed, Jul 27, 2016 at 11:04:04AM -0600, Martin Sebor wrote:
Just a couple of minor things:
+@cindex @code{fallthrough} statement attribute
+The @code{fallthrough} attribute with a null statement serves as a
+fallthrough statement. It hints to the compiler that a statement
+that falls through to another case label, or user-defined label
+in a switch statement is intentional and thus the
+@option{-Wimplicit-fallthrough} warning must not trigger. The
+fallthrough attribute might appear at most once in each attribute
+list, and might not be mixed with other attributes.
"Might appear" means that it may or may not appear (we don't know),
but the intent is to say that it's allowed to appear at most once.
Such a constraint is more correctly phrased in terms of either may
or or must, for example:
The fallthrough attribute may appear at most once.
or
The fallthrough attribute must not appear more than once.
Same for "might not be mixed with."
Oops, that's right. Fixed.
In (very light) testing I noticed that in the following, the switch
in h() is diagnosed but the one in g() is not.
Martin
int f (void);
#define foo() for ( ; ; ) { if (f ()) break; }
#define bar() do { if (f ()) break; } while (0)
int g (int i)
{
switch (i) {
case 0: foo ();
case 1: return 1;
}
return 0;
}
int h (int i)
{
switch (i) {
case 0: bar ();
case 1: return 1;
}
return 0;
}
Yeah, that is true. I'm not sure if the warning can reasonably be expected to
handle all such cases and really see through loops like that, most likely not.
It's really just a heuristics.
Fortunately I didn't see any false positives due to that while bootstrapping.
Can you add it as an xfail'd test?
jeff
