linux-kernel - Re: [PATCH 1/2] tools/nolibc: add support zero pad (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] [day] [month] [year] [list]

Message-ID: <CAAZOWcLdmCMkuuuYWb8cKn4_NJGci8u_p+wGvGg4wCFjhs137w@mail.gmail.com>
Date: Sat, 31 Jan 2026 11:44:23 +0800
From: Cheng Li <im.lechain@...il.com>
To: David Laight <david.laight.linux@...il.com>
Cc: Willy Tarreau <w@....eu>, Thomas Weißschuh <linux@...ssschuh.net>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] tools/nolibc: add support zero pad (0) in printf

David Laight <david.laight.linux@...il.com> 于2026年1月30日周五 22:58写道：
>
> On Fri, 30 Jan 2026 18:12:48 +0800
> Cheng Li <im.lechain@...il.com> wrote:
>
> > David Laight <david.laight.linux@...il.com> 于2026年1月30日周五 18:02写道：
> > >
> > > On Fri, 30 Jan 2026 16:37:35 +0800
> > > "licheng.li" <im.lechain@...il.com> wrote:
> > >
> > > > From: Cheng Li <im.lechain@...il.com>
> > > >
> > > > This patch correctly implements the '0' flag in __nolibc_printf() to
> > > > allow zero-padding for numeric and pointer outputs.
> > > >
> > > > Thanks to David for pointing out the errors in the previous implementation.
> > > >
> > > > The logic ensures that the sign ('-') for negative numbers or the prefix
> > > > ('0x') for pointers is printed before the padding zeros, adhering to
> > > > standard printf behavior (e.g., producing "-0005" instead of "000-5").
> > >
> > > I think it would be much better to change the contents of tmpbuf[]
> > > where it is filled with the converted number.
> > > You'd need to limit the number of zeros added (or the precision) to (say) 32
> > > and then set 'outbuf = tmpbuf + 32' so that the zeros and sign/0x can be
> > > added at the front.
> >
> > Hi David,
> >
> > You are absolutely right. Modifying the buffer generation logic
> > (tmpbuf) is indeed
> > the robust way to handle sign/prefix insertion combined with padding/precision.
> > My current approach of trying to handle it during the output phase is
> > too fragile
> > and misses edge cases (as I also realized regarding the negative sign issue).
> >
> > Given the complexity you mentioned (like the subtle differences in
> > standard compliance)
> > and your plan to implement full field precision, I will drop this
> > "Zero Padding" patch entirely.
> > It is better implemented as part of a proper precision support overhaul.
> >
> > I will focus on the "Left Alignment" patch. I am sending out v4 of
> > that series later,
> > which incorporates the code-swapping optimization you suggested earlier.
> >
> > Thanks for the detailed feedback.
>
> A good plan :-)
>
> I've written support for "%[#+- 0]*[.*][duxp]" but not tested the new bits yet.
>
> That is at +175 bytes after I used OPTIMZER_HIDE_VAR() to stop the compiler
> making a 'pigs breakfast' of the code (added nearly 100 bytes for a simple if()
> to avoid everything when the value and precision are both zero).

Hi David,

Glad to hear that! Implementing full spec support with such a small
footprint (+175 bytes)
sounds impressive. I look forward to seeing your patch series.

Thanks again for the review and suggestions on the left-alignment patch.

Best regards,
Cheng

>         David