Re: [PATCH v4 next 00/23] Enhance printf()

[Willy Tarreau]

Hi David,

On Mon, Mar 02, 2026 at 10:17:52AM +0000, david.laight.linux@xxxxxxxxx wrote:
> From: David Laight <david.laight.linux@xxxxxxxxx>
> 
> Update printf() so that it handles almost all the non-fp formats.
> In particular:
> - Left alignment.
> - Zero padding.
> - Alternate form "%#x" and "%#o".
> - Field precision.
> - Variable field width and precision.
> - Width modifiers q, L, t and z.
> - Conversion specifiers i, o and X (X generates lower case).
> About the only things that are missing are wide chanacters and floating point.
> 
> The tests are updated to match.
> 
> Bloat/savings (in nolibc-test, but excluding the program) to patch 14:
> (Measured for v3)
>     Function                                     old     new   delta
>     _nolibc_u64toa_base.isra                       -     143    +143
>     strerror                                       -      78     +78
>     __nolibc_sprintf_cb                           58      91     +33
>     itoa_r.isra                                   60      75     +15
>     utoa_r.isra                                  144       -    -144
>     __nolibc_printf                             1081     729    -352
> (All these functions include ~40 bytes for the stack protector code.)
> utoa_r.isra and _nolibc_u64toa_base.isra pretty much cancel each other out.
> itoa_r.isra grows slightly since it calls _nolibc_u64toa_base().
> strerror() used to be inlined, but over half of it is the stack check.
> While some of the code added to __nolibc_sprintf_cb() has come out of
> __nolibc_printf() 16-20 bytes is removed from the caller.
> So there is a net saving of about 280 bytes (including losing a copy of
> the number to ascii code).
> 
> The later patches add code back in:
>     patch 13 - conversion flags " +#"            +80 bytes
>     patch 14 - left aligning fields              +38 bytes
>     patch 15 - zero padding and field precision +260 bytes
>     patch 16 - octal output                      +34 bytes
> So probably about +130 bytes, but it will depend on what the application
> actually calls and inlining decisions made by the compiler.
> (All x86-64, other architectures will vary.)
> 
> The biggest size change is probably removing the .data from strerror().
> This reduced the program binary file by 4k if it is the only initialised
> data in a small program.

Thanks for this work. I'm personally fine with the series overall, even
though there are tiny comments here and there but nothing blocking. Let's
wait for Thomas' finaly review however.

I agree that having a more featureful printf() will definitely help in
various areas since it's used a lot in low-level userland code and testing.

Thanks,
Willy