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: <20260130145801.01d3908e@pumpkin>
Date: Fri, 30 Jan 2026 14:58:01 +0000
From: David Laight <david.laight.linux@...il.com>
To: Cheng Li <im.lechain@...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

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

	David