linux-kernel - Re: [PATCH v2 next 08/11] tools/nolibc/printf: Add support for zero padding and field precision

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: <20260208173118.4e565896@pumpkin>
Date: Sun, 8 Feb 2026 17:31:18 +0000
From: David Laight <david.laight.linux@...il.com>
To: Willy Tarreau <w@....eu>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
 linux-kernel@...r.kernel.org, Cheng Li <lechain@...il.com>
Subject: Re: [PATCH v2 next 08/11] tools/nolibc/printf: Add support for zero
 padding and field precision

On Sun, 8 Feb 2026 17:16:24 +0100
Willy Tarreau <w@....eu> wrote:

> On Fri, Feb 06, 2026 at 07:11:18PM +0000, david.laight.linux@...il.com wrote:
> > +				/* Add zero padding */
> > +				if (_NOLIBC_PF_FLAGS_CONTAIN(flags, '0', '.')) {
> > +					if (!_NOLIBC_PF_FLAGS_CONTAIN(flags, '.')) {
> > +						if (_NOLIBC_PF_FLAGS_CONTAIN(flags, '-'))
> > +							/* Left justify overrides zero pad */
> > +							goto prepend_sign;
> > +						/* eg "%05d", Zero pad to field width less sign */
> > +						precision = width;
> > +						if (sign) {
> > +							precision--;
> > +							if (sign >= 256)  
> 
> This is the one that confused me with previous patch. As long as we cannot
> have 4 chars that's OK, otherwise the 4th char can flip the sign. We could
> also add and unsigned cast here to clarify this, though admittedly this
> should not change over time.

The idea is that sign is 0/1/2 characters, a comment at the top might help. 

> Just for the record, this is the patch that increases the code the most
> (+265 bytes for me, no jump tables). But I think the feature is worth it
> and I'm not seeing low hanging fruits to reduce it. I honestly find the
> code particularly complex to follow now but that's related to the
> multiplicity of output formats and I doubt we can do much about this.

The final complexity is why I posted the full final version.
Trying to follow all the patches through is hard.
Some of the early changes are arranged to make the later ones smaller.

Yes it steals back all the gains from the previous patches and a bit more.
If you add the 'divide by reciprocal' [iu]64to[ah]_r() patch I think you
gain back at least two copies of the conversion code.
That might make it a net win.
The original code called u64toa_r(), u64toh_r() and i64toa_r() from
the numeric conversion code and utoa() from strerror().
Each copy is about 150 bytes on x86-64.
One copy is gone already, but I think there are two left.

That might give octal conversion at no net cost,

	David

> 
> Acked-by: Willy Tarreau <w@....eu>
> 
> Willy