clang 10 -Wimplicit-fallthrough

Darren Tucker dtucker at dtucker.net
Fri Jun 5 09:02:01 AEST 2020


Hi.

I upgraded my main build host and the clang -Werror builds started
failing.

This is because clang 10's -Wimplicit-fallthrough doesn't understand
/* FALLTHROUGH */ but rather requires __attribute__((fallthrough)):

clang -Wall -O2 [...] -Wimplicit-fallthrough [...] -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -DHAVE_CONFIG_H -c /openbsd-compat/base64.c
openbsd-compat/base64.c:284:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]

       case 3:         /* Valid, means two bytes of info */
openbsd-compat/base64.c:284:3: note: insert ´__attribute__((fallthrough));´ to silence this warning

None of our code has this (OpenSSH itself or the OpenBSD compat code) so
at the moment it makes the -Werror build useless with clang.  I'd like
to add a /* FALLTHROUGH */ to our test which will effectively disable
-Wimplicit-fallthrough where it is currently not useful to us:

$ clang --version
clang version 10.0.0 (Fedora 10.0.0-1.fc32)
$ CC=clang ../../configure
[...]
checking if clang supports compile flag -Wunused-result... yes
checking if clang supports compile flag -Wimplicit-fallthrough... no
checking if clang supports link flag -Wl,-z,retpolineplt... no

Can anyone suggest a better solution?  Annotating these points with a
FALLTHROUGH macro would make more work keeping the code in sync and so
is currently a non-starter.

diff --git a/aclocal.m4 b/aclocal.m4
index 25ecc49a..fca940dd 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -21,6 +21,11 @@ int main(int argc, char **argv) {
 	double m = l / 0.5;
 	long long int n = argc * 12345LL, o = 12345LL * (long long int)argc;
 	printf("%d %d %d %f %f %lld %lld\n", i, j, k, l, m, n, o);
+	switch(i){
+	case 0: j += i;
+		/* FALLTHROUGH */
+	default: j += k;
+	}
 	exit(0);
 }
 	]])],
-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


More information about the openssh-unix-dev mailing list