linux-kernel - Re: [PATCH v2 1/2] tools/nolibc: support left alignment (-) and zero padding (0) in printf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXsBANfAJdoTr8Iv@1wt.eu>
Date: Thu, 29 Jan 2026 07:41:04 +0100
From: Willy Tarreau <w@....eu>
To: "licheng.li" <im.lechain@...il.com>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] tools/nolibc: support left alignment (-) and zero
 padding (0) in printf

Hi Cheng,

On Wed, Jan 28, 2026 at 05:42:23PM +0800, licheng.li wrote:
> From: Cheng Li <im.lechain@...il.com>
> 
> Currently, __nolibc_printf() in nolibc parses the width field but always
> pads with spaces on the left. It ignores the '-' flag (left alignment)
> and treats leading zeros in the width as part of the number parsing
> (resulting in space padding instead of zero padding).
> 
> This patch implements support for:
> 1. The '-' flag: forces left alignment by padding spaces on the right.
> 2. The '0' flag: forces zero padding on the left instead of spaces.
> 
> The implementation reuses the padding character logic to handle both
> cases.
> 
> Logic behavior:
>  - "%5d"  -> "   12" (unchanged)
>  - "%-5d" -> "12   " (new: left align)
>  - "%05d" -> "00012" (new: zero pad)
>  - "%-05d"-> "12   " (new: left align overrides zero pad)
> 
> The code is optimized to keep the binary size impact minimal.
> Measuring the nolibc-test binary on x86_64:
> 
>   text    data     bss     dec     hex filename
>  43552     248     112   43912    ab88 nolibc-test (before)
>  43677     248     112   44037    ac05 nolibc-test (after)
> 
> The net increase is 125 bytes.

Is it normal this didn't change since previous patch, or did you just
forget to update that part of the commit message? In my case I'm seeing
a difference:

   text    data     bss     dec     hex filename
  35964     112     120   36196    8d64 nolibc-test-before
  36070     112     120   36302    8dce nolibc-test-after1 <- first patchset: +106
  36044     112     120   36276    8db4 nolibc-test-after2 <- this patchset: +80

If it's just an omission, I can edit the commit message if you paste
the new before/after in response, and save you from a respin just for
this! If it didn't change anything, that's possible as well, but
surprising, which is why I preferred to ask.

Thanks,
Willy