[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQm2366wMJ1K1fp7@smile.fi.intel.com>
Date: Tue, 4 Nov 2025 10:18:39 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: David Laight <david.laight.linux@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Guan-Chun Wu <409411716@....tku.edu.tw>,
Kuan-Wei Chiu <visitorckw@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] base64: Unroll the tables initialisers
On Mon, Nov 03, 2025 at 10:18:57PM +0000, David Laight wrote:
> On Mon, 3 Nov 2025 20:05:10 +0100
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:
>
> > Currently the initialisers of the tables have duplicate indices.
> > This prevents from building with `make W=1`.
> >
> > To address the issue, unroll the table initialisers with generated
> > arrays by the following Python excerpt:
> >
> > CHARS = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
> >
> > def gen_table(ch62, ch63):
> > table = [ 0xff ] * 256
> > for idx, char in enumerate(CHARS):
> > table[ord(char)] = idx
> > table[ord(ch62)] = 62
> > table[ord(ch63)] = 63
> >
> > for i in range(0, len(table), 8):
> > print (f"\t{', '.join(f"0x{c:02x}" for c in table[i:i+8])},\t/* {i:-3d} - {i+7:-3d} */")
...
> > + [BASE64_STD] = {
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0 - 7 */
>
> You need to use -1 not 0xff.
Whu? The s8 type is pretty much 8-bit, care to explain the point?
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 8 - 15 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 16 - 23 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 24 - 31 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 32 - 39 */
>
> Nothing wrong with [ 0 ... 39 ] = -1,
Have you tried? It's unreadable if we use ranges.
> > + 0xff, 0xff, 0xff, 0x3e, 0xff, 0xff, 0xff, 0x3f, /* 40 - 47 */
> > + 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, /* 48 - 55 */
> > + 0x3c, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 56 - 63 */
> > + 0xff, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, /* 64 - 71 */
> > + 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, /* 72 - 79 */
> > + 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, /* 80 - 87 */
> > + 0x17, 0x18, 0x19, 0xff, 0xff, 0xff, 0xff, 0xff, /* 88 - 95 */
> > + 0xff, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, /* 96 - 103 */
> > + 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, /* 104 - 111 */
> > + 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, /* 112 - 119 */
> > + 0x31, 0x32, 0x33, 0xff, 0xff, 0xff, 0xff, 0xff, /* 120 - 127 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 128 - 135 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 136 - 143 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 144 - 151 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 152 - 159 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 160 - 167 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 168 - 175 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 176 - 183 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 184 - 191 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 192 - 199 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 200 - 207 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 208 - 215 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 216 - 223 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 224 - 231 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 232 - 239 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 240 - 247 */
> > + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 248 - 255 */
> > + },
...
> This is impenetrable crap...
Send your version for the review, please, we still have a build issue here.
But I definitely do not like current state of affairs.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists