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

[Tom Rini]

On Thu, Mar 20, 2025 at 05:58:56PM +0000, Christoph Niedermaier wrote:
> From: Tom Rini <trini at 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 at 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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250320/1408ceec/attachment.sig>