From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Guan-Chun Wu <409411716@gms.tku.edu.tw>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
stable@vger.kernel.org
Subject: Re: [PATCH] lib/base64: Silence clang-24 -Wconstant-conversion with diag pragmas
Date: Sat, 10 Oct 2026 00:59:01 +0800 [thread overview]
Message-ID: <askdVfevxztHMyGN@google.com> (raw)
In-Reply-To: <20261008-base64-silence-clang-24-constant-conversion-v1-1-0858b60b23c8@kernel.org>
On Thu, Oct 08, 2026 at 01:08:49PM +0200, Nathan Chancellor wrote:
> After a recent change in clang to warn on signed char conversions within
> array initializers [1], there are several instances of this warning from
> base64_rev_maps in lib/base64.c, which can break the build with W=e or
> CONFIG_WERROR=y:
>
> lib/base64.c:58:18: error: implicit conversion from 'int' to 's8' (aka 'signed char') changes value from 131 to -125 [-Werror,-Wconstant-conversion]
> 58 | [BASE64_IMAP] = BASE64_REV_INIT('+', ',')
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> lib/base64.c:52:2: note: expanded from macro 'BASE64_REV_INIT'
> 48 | #define BASE64_REV_INIT(ch_62, ch_63) { \
> | ~
> 49 | [0 ... 0x1f] = -1, \
> 50 | INIT_32(0x20, ch_62, ch_63), \
> 51 | INIT_32(0x40, ch_62, ch_63), \
> 52 | INIT_32(0x60, ch_62, ch_63), \
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
> lib/base64.c:34:42: note: expanded from macro 'INIT_1'
> 34 | : (v) >= '0' && (v) <= '9' ? (v) - '0' + 52 \
> | ~~~~~~~~~~^~~~
> lib/base64.c:58:18: error: implicit conversion from 'int' to 's8' (aka 'signed char') changes value from 130 to -126 [-Werror,-Wconstant-conversion]
> 58 | [BASE64_IMAP] = BASE64_REV_INIT('+', ',')
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> lib/base64.c:52:2: note: expanded from macro 'BASE64_REV_INIT'
> 48 | #define BASE64_REV_INIT(ch_62, ch_63) { \
> | ~
> 49 | [0 ... 0x1f] = -1, \
> 50 | INIT_32(0x20, ch_62, ch_63), \
> 51 | INIT_32(0x40, ch_62, ch_63), \
> 52 | INIT_32(0x60, ch_62, ch_63), \
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
> lib/base64.c:34:42: note: expanded from macro 'INIT_1'
> 34 | : (v) >= '0' && (v) <= '9' ? (v) - '0' + 52 \
> | ~~~~~~~~~~^~~~
> ...
>
> These are false positives, as the branch where the wraparound could
> happen is unreachable with the values that clang reports. This is not
> considered a bug by some clang folks [2][3], so silence the warnings
> using the __diag macros the kernel has to workaround compiler warnings
> when necessary.
>
> Cc: stable@vger.kernel.org
> Fixes: c4eb7ad32eab ("lib/base64: optimize base64_decode() with reverse lookup tables")
> Closes: https://github.com/ClangBuiltLinux/linux/issues/2181
> Link: https://github.com/llvm/llvm-project/commit/a5ef934a8d295dc03be3960f2b3744ec2e53238e [1]
> Link: https://github.com/llvm/llvm-project/issues/223923#issuecomment-6056856245 [2]
> Link: https://github.com/llvm/llvm-project/pull/226775#pullrequestreview-5454407389 [3]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reading the issue comment in the link, it seems somewhat subjective and
controversial whether the compiler should emit a warning in this
scenario. I'm not a compiler expert, but from a user's perspective,
it's a bit disappointing when we have to deal with this. When we are
confident that the code is correct and have provided the compiler with
enough context to determine that there is no runtime issue, suddenly
getting a new warning after an upgrade is a bit frustrating. But
anyway, let's go with this workaround to keep the compiler happy.
Regards,
Kuan-Wei
> ---
> lib/base64.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/base64.c b/lib/base64.c
> index 325c7332b049..e46be3a55585 100644
> --- a/lib/base64.c
> +++ b/lib/base64.c
> @@ -52,11 +52,14 @@ static const char base64_tables[][65] = {
> INIT_32(0x60, ch_62, ch_63), \
> [0x80 ... 0xff] = -1 }
>
> +__diag_push();
> +__diag_ignore(clang, all, "-Wconstant-conversion", "https://github.com/llvm/llvm-project/issues/223923");
> static const s8 base64_rev_maps[][256] = {
> [BASE64_STD] = BASE64_REV_INIT('+', '/'),
> [BASE64_URLSAFE] = BASE64_REV_INIT('-', '_'),
> [BASE64_IMAP] = BASE64_REV_INIT('+', ',')
> };
> +__diag_pop();
>
> #undef BASE64_REV_INIT
> #undef INIT_32
>
> ---
> base-commit: 0c2669a9f4a1d607e7591ae50ccf3c432a0aff08
> change-id: 20261008-base64-silence-clang-24-constant-conversion-b682c6bbf563
>
> Best regards,
> --
> Cheers,
> Nathan
>
next prev parent reply other threads:[~2026-10-09 16:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 11:08 Nathan Chancellor
2026-10-09 16:59 ` Kuan-Wei Chiu [this message]
2026-10-09 20:38 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=askdVfevxztHMyGN@google.com \
--to=visitorckw@gmail.com \
--cc=409411716@gms.tku.edu.tw \
--cc=akpm@linux-foundation.org \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®