linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Guan-Chun Wu <409411716@gms.tku.edu.tw>,
	David Laight <david.laight.linux@gmail.com>
Subject: Re: [akpm-mm:mm-nonmm-unstable 87/91] lib/base64.c:36:28: sparse: sparse: Initializer entry defined twice
Date: Sun, 2 Nov 2025 21:42:36 +0800	[thread overview]
Message-ID: <aQdfzCq2JH5QX9AH@google.com> (raw)
In-Reply-To: <202511021343.107utehN-lkp@intel.com>

+Cc David

On Sun, Nov 02, 2025 at 01:36:16PM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> head:   97751db460a7c6988b2ab988d9889d4309f9cc8c
> commit: 5b693a7ad2acfa88e8ab0a047335ea4c94fecdb1 [87/91] lib/base64: optimize base64_decode() with reverse lookup tables
> config: m68k-randconfig-r123-20251102 (https://download.01.org/0day-ci/archive/20251102/202511021343.107utehN-lkp@intel.com/config)
> compiler: m68k-linux-gcc (GCC) 14.3.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251102/202511021343.107utehN-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202511021343.107utehN-lkp@intel.com/
> 
> sparse warnings: (new ones prefixed by >>)
> >> lib/base64.c:36:28: sparse: sparse: Initializer entry defined twice
>    lib/base64.c:36:28: sparse:   also defined here
>    lib/base64.c:37:25: sparse: sparse: Initializer entry defined twice
>    lib/base64.c:37:25: sparse:   also defined here
> 

I guess this warning is triggered because we first initialize the array
with [0 ... 255] = -1, and then re-assign values for ['A'], ['a'],
['0'], as well as the 62nd and 63rd characters.

This approach was adopted based on David's suggestion [1] to improve
readability by avoiding the expansion of the large 256 * 3 table.

I'm uncertain whether we should reconsider this method to avoid the
warning, or if it's safe to ignore it in this case?

[1]: https://lore.kernel.org/lkml/20250928195736.71bec9ae@pumpkin/

Regards,
Kuan-Wei

> vim +36 lib/base64.c
> 
>     33	
>     34	static const s8 base64_rev_maps[][256] = {
>     35		[BASE64_STD] = BASE64_REV_INIT('+', '/'),
>   > 36		[BASE64_URLSAFE] = BASE64_REV_INIT('-', '_'),
>     37		[BASE64_IMAP] = BASE64_REV_INIT('+', ',')
>     38	};
>     39	/**
>     40	 * base64_encode() - Base64-encode some binary data
>     41	 * @src: the binary data to encode
>     42	 * @srclen: the length of @src in bytes
>     43	 * @dst: (output) the Base64-encoded string.  Not NUL-terminated.
>     44	 * @padding: whether to append '=' padding characters
>     45	 * @variant: which base64 variant to use
>     46	 *
>     47	 * Encodes data using the selected Base64 variant.
>     48	 *
>     49	 * Return: the length of the resulting Base64-encoded string in bytes.
>     50	 */
>     51	int base64_encode(const u8 *src, int srclen, char *dst, bool padding, enum base64_variant variant)
>     52	{
>     53		u32 ac = 0;
>     54		int bits = 0;
>     55		int i;
>     56		char *cp = dst;
>     57		const char *base64_table = base64_tables[variant];
>     58	
>     59		for (i = 0; i < srclen; i++) {
>     60			ac = (ac << 8) | src[i];
>     61			bits += 8;
>     62			do {
>     63				bits -= 6;
>     64				*cp++ = base64_table[(ac >> bits) & 0x3f];
>     65			} while (bits >= 6);
>     66		}
>     67		if (bits) {
>     68			*cp++ = base64_table[(ac << (6 - bits)) & 0x3f];
>     69			bits -= 6;
>     70		}
>     71		if (padding) {
>     72			while (bits < 0) {
>     73				*cp++ = '=';
>     74				bits += 2;
>     75			}
>     76		}
>     77		return cp - dst;
>     78	}
>     79	EXPORT_SYMBOL_GPL(base64_encode);
>     80	
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki


  reply	other threads:[~2025-11-02 13:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02  5:36 kernel test robot
2025-11-02 13:42 ` Kuan-Wei Chiu [this message]
2025-11-02 14:42   ` David Laight
2025-11-02 14:57     ` Kuan-Wei Chiu

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=aQdfzCq2JH5QX9AH@google.com \
    --to=visitorckw@gmail.com \
    --cc=409411716@gms.tku.edu.tw \
    --cc=akpm@linux-foundation.org \
    --cc=david.laight.linux@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    /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