RE: [PATCH] tiny-printf: Add support for upper case hex values

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

From: Tom Rini <trini@konsulko.com>
Sent: Thursday, March 20, 2025 3:19 PM
> On Thu, Mar 20, 2025 at 03:14:03PM +0100, Marek Vasut wrote:
> > On 3/20/25 3:00 PM, Quentin Schulz wrote:
> > > Hi Marek,
> > >
> > > On 3/20/25 12:49 PM, Marek Vasut wrote:
> > > > On 3/20/25 11:23 AM, Christoph Niedermaier wrote:
> > > > > If tiny printf is used with 0x%08X (upper case X) the output is
> > > > > always 0x00000000. It could be confusing if upper case instead
> > > > > of lower case is used intentionally or accidentally because the
> > > > > actual value is not output. To avoid this confusion, tiny printf
> > > > > is extended to support also the formatting with %X.
> > > > >
> > > > > Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
> > > > TINY_PRINTF is meant to be tiny, i.e. not consume a lot of space, at
> > > > the expense of functionality. This is meant to be used in size
> > > > constrained environments, like the SPL. If you need full vsprintf()
> > > > formatting support, disable TINY_PRINTF in your config and use the
> > > > regular vsprintf() implementation.
> > >
> > > The issue is that disabling TINY_PRINTF may not be possible (size
> > > constraints) and some code is compiled for different stages and people
> > > typically don't check whether the format used in printf is valid with
> > > tiny_printf. I've had this issue already in the past, I vaguely recall
> > > "complaining" about it on IRC.
> > >
> > > Maybe there's something we can do to verify that the code is working how
> > > we expect it to work, regardless of tiny_printf/full printf selection?
> > > checkpatch or a compile-time check for the formats maybe?
> > >
> > > But yeah, essentially the whole thing is... if we continue like this,
> > > we'll just end up getting closer and closer to the full printf which is
> > > not something we want :)
> > Shall we maybe patch tiny printf to print '?' on unsupported formatting
> > characters, or outright complain that users should fix their code ?
> 
> This sounds good to me, adding ? in the output.
> 
> > For the %x/%X thing, we could technically fall back from %X to %x , which
> > would do the printing with minimum footprint increase, albeit slightly
> > malformed:
> 
> There's 109 hits on "%X" and another 489 on "%0.X", so I think it's
> reasonable to do either of:
> - Misprint A-F as a-f (in other words, treat it like 'x'
> - Audit the callers and change them to 'x' from 'X'. We normally don't
>   capitalize the output and there's all sorts of patches over the years
>   changing them to lowercase in other places.
> 
> We have done both for other format specifiers and tiny-printf before in
> the past.

If we taking about adding feature, I think that the patch don't really
add a new feature, it's just a variant of %x. I reuse part of the %x code.
So if size matters here the size of the object file (not stripped):

Before:
-rw-r--r-- 1 developer developer 19340 Mar 20 15:32 tiny-printf.o

After with current patch:
-rw-r--r-- 1 developer developer 21212 Mar 20 15:38 tiny-printf.o
=> Diff: 1872 Bytes (+9,67%)

I have another patch, where I don't introduce two new function and
don't use an enum. Then it looks like this:
-rw-r--r-- 1 developer developer 19888 Mar 20 16:53 tiny-printf.o
=> Diff: 548 Bytes (+2,83%)

Would this increase in size be OK for %X?
So there will be no misprint.

Otherwise, a misprint for %X would be fine with me, because I still
get the correct value.


Regards
Christoph