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: <CAAZOWcJQzA9Ed_wgOb-4VZ8ofvViKbCysUS7ZeUqcmo=yZ8sCw@mail.gmail.com>
Date: Thu, 29 Jan 2026 14:57:26 +0800
From: licheng <im.lechain@...il.com>
To: Willy Tarreau <w@....eu>
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 Willy,

Willy Tarreau <w@....eu> 于2026年1月29日周四 14:41写道：
>
> 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 for catching this! You are right, I missed updating the binary
size data in the v2 commit message. I performed the previous measurement
using the simplest command: `make -C tools/testing/selftests/nolibc'

The discrepancy in absolute numbers is likely caused by the different compiler
versions and optimization levels between our environments. Since your
environment
shows a more accurate delta for the current upstream state, please feel free to
update the commit message  directly to save a respin.

Thank you for your help and for the detailed review!
Best regards, Cheng Li

> Thanks,
> Willy