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: <aXsHHh5qrBgMW4PY@1wt.eu>
Date: Thu, 29 Jan 2026 08:07:10 +0100
From: Willy Tarreau <w@....eu>
To: licheng <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

On Thu, Jan 29, 2026 at 02:57:26PM +0800, licheng wrote:
> 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'

OK!

> 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.

OK will do. I'll handle this this week-end unless Thomas has other
comments or beats me at it. In case I forget, do not hesitate to ping
me early next week ;-)

thanks,
Willy