[llvm-bugs] [Bug 43465] New: False positive -Wimplicit-fallthrough warning in flex-generated C code
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Sep 26 07:30:04 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=43465
Bug ID: 43465
Summary: False positive -Wimplicit-fallthrough warning in
flex-generated C code
Product: new-bugs
Version: trunk
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: sean at rogue-research.com
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
Consider this C code:
-------------------
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
int x = random();
switch (x)
{
case 1:
printf("case1");
/*FALLTHROUGH*/
default:
printf("default");
}
return 0;
}
-------------------
clang trunk (but not the current release, 9.0) with -Wimplicit-fallthrough
warns:
-------------------
<source>:12:5: warning: unannotated fall-through between switch labels
[-Wimplicit-fallthrough]
default:
^
<source>:12:5: note: insert '__attribute__((fallthrough));' to silence this
warning
default:
^
__attribute__((fallthrough));
<source>:12:5: note: insert 'break;' to avoid fall-through
default:
^
break;
-------------------
gcc 7.x and later do *not* warn, because they detect the comment
"/*FALLTHROUGH*/" and take it as a cue that it's deliberately. This is
documented here:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-fallthrough
Compare on godbolt:
https://godbolt.org/z/UFpfNm
It would be nice if clang did the same. Especially since the venerable flex
<https://github.com/westes/flex> generates code that uses exactly that comment.
Without this, clang will start giving false positive warnings (that gcc does
not) on lots of flex-generated code out there.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190926/a1d869b6/attachment-0001.html>
More information about the llvm-bugs
mailing list