[PATCH] tiny-printf: Support %i

[Marek Vasut]

On 4/14/20 4:18 AM, Simon Glass wrote:
> 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.

It seems to me that Toms counter-argument is code size.

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

I think I mentioned it before, what about bypassing uclasses which have
only one driver instance in them . Then the whole code for tracking
instances can be optimized away for that particular uclass, which should
save quite a bit of space.

> 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?

You are wrong, I am not opposed to adding tests. I am opposed to
blocking trivial patches which take minutes to implement by requesting
adding an entire class of tests, which would likely take days to
implement properly. That sheer difference in magnitude does not sound
right to me.