diff options
| author | Nathan Chancellor <nathan@kernel.org> | 2026-10-08 13:08:49 +0200 |
|---|---|---|
| committer | Andrew Morton <akpm@linux-foundation.org> | 2026-10-08 23:04:46 -0700 |
| commit | 07f9e0ed9f8284625569bf2e21cae0c842c87a5d (patch) | |
| tree | e0f56046722528caf6a7e9de926aa7487bb486e0 /tools/lib/python/kdoc/python_version.py | |
| parent | 8d1c2341b40a0e9555ba25f1fa06eefa0ffc0cca (diff) | |
| download | linux-next-07f9e0ed9f8284625569bf2e21cae0c842c87a5d.tar.gz linux-next-07f9e0ed9f8284625569bf2e21cae0c842c87a5d.zip | |
lib/base64: silence clang-24 -Wconstant-conversion with diag pragmas
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.
Link: https://lore.kernel.org/20261008-base64-silence-clang-24-constant-conversion-v1-1-0858b60b23c8@kernel.org
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]
Fixes: c4eb7ad32eab ("lib/base64: optimize base64_decode() with reverse lookup tables")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2181
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Bill Wendling <morbo@google.com>
Cc: Justin Stitt <justinstitt@google.com>
Cc: Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: Guan-Chun Wu <409411716@gms.tku.edu.tw>
Cc: <stable@vger.kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
