From: Tom Rini <tr...@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 <cniederma...@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
