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 7:28 PM
> On Thu, Mar 20, 2025 at 05:58:56PM +0000, Christoph Niedermaier wrote:
> > 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.
> 
> Tiny really does mean tiny in this case so yes, I would prefer the
> single digit byte increase of adding 'X' to the 'x' case. Thanks!

OK, I will make a V2 with this changes.


Regards
Christoph