Re: [PATCH] lib/base64: fix -Wconstant-conversion warning in INIT_1()

[Nathan Chancellor]

Hi Rosalie,

On Tue, Nov 03, 2026 at 04:34:04PM +0000, Rosalie Fang wrote:
> When expanding BASE64_REV_INIT() for v in 0x7c..0x7f (124..127), the
> unselected ternary branch (v) - '0' + 52 evaluates to 128..131, which
> exceeds SCHAR_MAX (127). Recent Clang versions diagnose implicit integer
> constant conversions in unevaluated ternary arms when initializing the
> s8 lookup tables:
> 
>   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:34:42: note: expanded from macro 'INIT_1'
>      34 |                 : (v) >= '0' && (v) <= '9' ? (v) - '0' + 52 \
>         |                                              ~~~~~~~~~~^~~~
> 
> Explicitly cast the digit-branch expression to s8 to silence the
> warning.
> 
> Fixes: c4eb7ad32eab ("lib/base64: optimize base64_decode() with reverse lookup tables")
> Assisted-by: LLM
> Signed-off-by: Rosalie Fang <rosaliefang@xxxxxxxxxx>
> ---
>  lib/base64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/base64.c b/lib/base64.c
> index 325c7332b049..1489c048b1fd 100644
> --- a/lib/base64.c
> +++ b/lib/base64.c
> @@ -31,7 +31,7 @@ static const char base64_tables[][65] = {
>  #define INIT_1(v, ch_62, ch_63) \
>  	[v] = (v) >= 'A' && (v) <= 'Z' ? (v) - 'A' \
>  		: (v) >= 'a' && (v) <= 'z' ? (v) - 'a' + 26 \
> -		: (v) >= '0' && (v) <= '9' ? (v) - '0' + 52 \
> +		: (v) >= '0' && (v) <= '9' ? (s8)((v) - '0' + 52) \
>  		: (v) == (ch_62) ? 62 : (v) == (ch_63) ? 63 : -1
>  
>  /*
> -- 
> 2.56.0.385.gac671c819a-goog
> 

Thanks for the change. I avoided this in a different way, which has
recently been merged into a tree that should be merged into mainline
relatively soon:

  https://git.kernel.org/akpm/mm/c/3af83c11cf5990fda0bfe3959aa6391ff903ffdd

For the record, I do hope that

  https://github.com/llvm/llvm-project/pull/226775

eventually gets merged so that these workarounds will be unnecessary but
I am not sure how that will play out yet.

-- 
Cheers,
Nathan