Re: [PATCH v5 next 00/17] Enhance printf()

[Willy Tarreau]

On Sun, Mar 08, 2026 at 11:37:25AM +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 11:
> (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.
> 
> Changes for v5:
> - Old patches 2 to 7 have been applied to nolibc-next and removed.
> - Patch 3 changed to return the correct (success/fail not length)
>   value from strerror_r() and to return ERANGE if the buffer is short.
> - Patch 11 (prepend sign) has an updated comment.

Thank you David. For me this is all OK. Great work!

Willy