Hello,
On Mon, Apr 13, 2026 at 09:24:17AM +0200, Simon Josefsson wrote: [..]
hex_digits[16] = { '0', '1', '2', ... 'e', 'f' };
I'm hoping no compiler complains about missing ASCII NUL in a "string" defined that way.
The compilers available on gotbolt don't complain:
https://godbolt.org/z/Whb9Eh36q
Several base64 implementations use the last approach, but mostly for EBCDIC compatibility rather than to pacify false positive compiler warnings. Do Nettle care about EBCDIC targets? Gnulib's base64 code
FWIW, I would only worry about EBCDIC after somebody shows up who has a plausible use-case.
has the snippet below, but it assumes 'char' is 8-bit.
I'm sorry, but this gnulib code is horrible.
Why are they over-using the c pre-processor like this ... I mean since gnulib is configure-time checking the world anyway they could simply detect EBCDIC at configure time and conditonally guard/include full ASCII/EBCDIC arrays based on that result. Or even generating the array in M4 or some ultra-portable form of shell at configure time would be a more sensible approach than this.
#define B64(_) \ ((_) == 'A' ? 0 \ : (_) == 'B' ? 1 \ : (_) == 'C' ? 2 \ : (_) == 'D' ? 3 \ ... : (_) == '8' ? 60 \ : (_) == '9' ? 61 \ : (_) == '+' ? 62 \ : (_) == '/' ? 63 \ : -1)
signed char const base64_to_int[256] = { B64 (0), B64 (1), B64 (2), B64 (3), ... B64 (252), B64 (253), B64 (254), B64 (255) };
Best regards, Georg