After enabling -Wimplicit-fallthrough for the x86 boot code, clang
warns:
arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
257 | case 'u':
| ^
Clang is a little more pedantic than GCC, which does not warn when
falling through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst, which
states that all switch/case blocks must end in either break,
fallthrough, continue, goto, or return. Add the missing break to silence
the warning.
Fixes: dd0716c2b877 ("x86/boot: Add a fallthrough annotation")
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Nathan Chancellor <[email protected]>
---
arch/x86/boot/printf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/boot/printf.c b/arch/x86/boot/printf.c
index c0ec1dc355ab..51dc14b714f6 100644
--- a/arch/x86/boot/printf.c
+++ b/arch/x86/boot/printf.c
@@ -254,6 +254,8 @@ int vsprintf(char *buf, const char *fmt, va_list args)
case 'd':
case 'i':
flags |= SIGN;
+ break;
+
case 'u':
break;
---
base-commit: dd0716c2b87792ebea30864e7ad1df461d4c1525
change-id: 20240516-x86-boot-fix-clang-implicit-fallthrough-fc5c9bb19765
Best regards,
--
Nathan Chancellor <[email protected]>
On Thu, May 16, 2024 at 7:03 AM Nathan Chancellor <[email protected]> wrote:
>
> After enabling -Wimplicit-fallthrough for the x86 boot code, clang
> warns:
>
> arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
> 257 | case 'u':
> | ^
>
> Clang is a little more pedantic than GCC, which does not warn when
> falling through to a case that is just break or return. Clang's version
> is more in line with the kernel's own stance in deprecated.rst, which
> states that all switch/case blocks must end in either break,
> fallthrough, continue, goto, or return. Add the missing break to silence
> the warning.
>
> Fixes: dd0716c2b877 ("x86/boot: Add a fallthrough annotation")
> Reported-by: kernel test robot <[email protected]>
> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> Signed-off-by: Nathan Chancellor <[email protected]>
Seems simple enough.
Acked-by: Justin Stitt <[email protected]>
> ---
> arch/x86/boot/printf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/boot/printf.c b/arch/x86/boot/printf.c
> index c0ec1dc355ab..51dc14b714f6 100644
> --- a/arch/x86/boot/printf.c
> +++ b/arch/x86/boot/printf.c
> @@ -254,6 +254,8 @@ int vsprintf(char *buf, const char *fmt, va_list args)
> case 'd':
> case 'i':
> flags |= SIGN;
> + break;
> +
> case 'u':
> break;
>
>
> ---
> base-commit: dd0716c2b87792ebea30864e7ad1df461d4c1525
> change-id: 20240516-x86-boot-fix-clang-implicit-fallthrough-fc5c9bb19765
>
> Best regards,
> --
> Nathan Chancellor <[email protected]>
>
On Thu, May 16, 2024 at 07:03:41AM -0700, Nathan Chancellor wrote:
> After enabling -Wimplicit-fallthrough for the x86 boot code, clang
> warns:
>
> arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
> 257 | case 'u':
> | ^
>
> Clang is a little more pedantic than GCC, which does not warn when
> falling through to a case that is just break or return.
Is anyone fixing Clang?
:-P
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, May 17, 2024 at 11:51:10AM +0200, Borislav Petkov wrote:
> On Thu, May 16, 2024 at 07:03:41AM -0700, Nathan Chancellor wrote:
> > After enabling -Wimplicit-fallthrough for the x86 boot code, clang
> > warns:
> >
> > arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
> > 257 | case 'u':
> > | ^
> >
> > Clang is a little more pedantic than GCC, which does not warn when
> > falling through to a case that is just break or return.
>
> Is anyone fixing Clang?
>
> :-P
There was a patch to make Clang match GCC's behavior a few years ago but
I think Kees made a good argument that GCC's behavior leaves potential
bugs on the table, so that was not pursued further.
https://reviews.llvm.org/D91895#2417170
It was brought up to GCC as well but they did not want to change their
behavior:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
Cheers,
Nathan
On Fri, May 17, 2024 at 08:18:33AM -0700, Nathan Chancellor wrote:
> There was a patch to make Clang match GCC's behavior a few years ago but
> I think Kees made a good argument that GCC's behavior leaves potential
> bugs on the table, so that was not pursued further.
>
> https://reviews.llvm.org/D91895#2417170
Really? Maybe I'm being dense but I don't see real bugs there... I see
readability issues. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, May 23, 2024 at 01:57:34PM +0200, Borislav Petkov wrote:
> On Fri, May 17, 2024 at 08:18:33AM -0700, Nathan Chancellor wrote:
> > There was a patch to make Clang match GCC's behavior a few years ago but
> > I think Kees made a good argument that GCC's behavior leaves potential
> > bugs on the table, so that was not pursued further.
> >
> > https://reviews.llvm.org/D91895#2417170
>
> Really? Maybe I'm being dense but I don't see real bugs there... I see
> readability issues. :-)
There isn't a bug _here_, but this is about making the code unambiguous
everywhere in the kernel. We've already done the work to get rid of
all these warnings; this one is newly introduced, so let's get it fixed.
We don't want to have the same flow-control statement reachable from two
different "case"s where the resulting behaviors are different. Otherwise
we can't determine if a "fallthrough" is missing or intentional.
Reviewed-by: Kees Cook <[email protected]>
-Kees
--
Kees Cook
On Thu, May 23, 2024 at 04:12:25PM -0700, Kees Cook wrote:
> There isn't a bug _here_, but this is about making the code unambiguous
> everywhere in the kernel. We've already done the work to get rid of
> all these warnings; this one is newly introduced, so let's get it fixed.
Nah, it has been there since forever (forever == 2007 in this case). It
fires because I enabled the warning in the decompressor.
> We don't want to have the same flow-control statement reachable from two
> different "case"s where the resulting behaviors are different. Otherwise
> we can't determine if a "fallthrough" is missing or intentional.
I'd agree if this warning wasn't enabled by default but were a W=123...
diagnostic thing which does the additional checks. But right now clang
is warning for a perfectly valid, albeit a bit confusing C.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette