[PATCH] tiny-printf: Support %i

Simon Glass sjg at chromium.org
Tue Apr 14 04:18:13 CEST 2020


Hi Marek,

On Mon, 13 Apr 2020 at 19:18, Marek Vasut <marex at denx.de> wrote:
>
> On 4/14/20 1:27 AM, Tom Rini wrote:
> > On Fri, Apr 10, 2020 at 08:54:49PM +0200, Marek Vasut wrote:
> >
> >> The most basic printf("%i", value) formating string was missing,
> >> add it for the sake of convenience.
> >>
> >> Signed-off-by: Marek Vasut <marex at denx.de>
> >> Cc: Simon Glass <sjg at chromium.org>
> >> Cc: Stefan Roese <sr at denx.de>
> >> ---
> >>  lib/tiny-printf.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
> >> index 1138c7012a..8fc7e48d99 100644
> >> --- a/lib/tiny-printf.c
> >> +++ b/lib/tiny-printf.c
> >> @@ -242,6 +242,7 @@ static int _vprintf(struct printf_info *info, const char *fmt, va_list va)
> >>                              goto abort;
> >>                      case 'u':
> >>                      case 'd':
> >> +                    case 'i':
> >>                              div = 1000000000;
> >>                              if (islong) {
> >>                                      num = va_arg(va, unsigned long);
> >> @@ -251,7 +252,7 @@ static int _vprintf(struct printf_info *info, const char *fmt, va_list va)
> >>                                      num = va_arg(va, unsigned int);
> >>                              }
> >>
> >> -                            if (ch == 'd') {
> >> +                            if (ch != 'u') {
> >>                                      if (islong && (long)num < 0) {
> >>                                              num = -(long)num;
> >>                                              out(info, '-');
> >
> > How much does the size change and where do we see this as a problem?
>
> Any code which uses %i in SPL just misbehaves, e.g.
> printf("%s[%i] value=%x", __func__, __LINE__, val);
> prints function name and then incorrect value, because %i is ignored.
> This is also documented in the commit message.
>
> U-Boot grows in size massively due to all the DM/DT bloat which is being
> forced upon everyone, but there the uncontrolled growth is apparently OK
> even if it brings no obvious improvement, rather the opposite. And yet
> here, size increase suddenly matters? Sorry, that's not right.
>
> The code grows by 6 bytes.

This is not an issue of code size. It is simply that we have a lot of
untested code, and we all need to club together to fix that.

Re DM/DT, if you have thoughts on how to improve it, please let me
know. I am very concerned about it also.

If some of the most senior maintainers in U-Boot are so opposed to
adding tests with new code, how do we expect others to make the
effort? Marek, you were one of the most vocal advocates of a longer
release cycle because you were seeing lots of breakage that
maintainers didn't have time to find. How do I square that with the
avoidance of adding tests?

Regards,
Simon


More information about the U-Boot mailing list