Hi Hiren,

I see two bugs in the code

1. TF-A does not place ‘\0’ at the end of the buffer. I propose that we always place ‘\0’ at the end of the buffer, so that clients can see truncated strings instead of an empty string.
2. The off-by-one issue originally reported

I invite you to push patches to the TF-A gerrit to discuss these issues further.

-Varun

From: Hiren Mehta <mehta_hiren@yahoo.com>
Sent: Wednesday, June 2, 2021 5:01 PM
To: Varun Wadekar <vwadekar@nvidia.com>
Cc: tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] issue with vsnprintf() and unsigned_num_print()

External email: Use caution opening links or attachments

Hi Varun,

Thank you very much for your attention.

The issue that we have observed is: 

char mystr[5];

snprintf(mystr, sizeof(mystr), "%04x", 0xabc);

After the execution of snprintf, mystr is set to "" (empty string). I was expecting it to be set to "0abc".

As you can see above, mystr has space for printing 4 hex chars and a terminating NULL char.

If I change it to:

char mystr[6];

snprintf(mystr, sizeof(mystr), "%04x", 0xabc);

Then, I get "0abc" in 'mystr' string.

The issue seems to be specific to number printing.

I will be happy to provide more examples if you need them.

Thanks,

-hiren

On Wednesday, June 2, 2021, 02:10:27 AM PDT, Varun Wadekar <vwadekar@nvidia.com> wrote:

HI Hiren,

Can you please add more color to “even if I provide large enough string to hold the number, it does not print it”?

Are you saying that the library prints a partial value? If the calculation is off by 1, I assume, the library should at least print a partial value.

-Varun

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Hiren Mehta via TF-A
Sent: Saturday, May 29, 2021 9:41 AM
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] issue with vsnprintf() and unsigned_num_print()

External email: Use caution opening links or attachments

Hi All,

We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4

and running into an issue for printing a number into a string where even if I provide large enough string to hold the 

number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf().

I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case,

that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do.

I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bug

in the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculating

the available space in the string.

 if (*chars_printed < n) {

     .... do the prinring....

}

I believe it is supposed to be

 if (*chars_printed <= n) {   ----------------->> Notice '<=' instead of '<' 

}

Any comment on whether this is on purpose or really a small bug?

The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character.

Thank you very much for your support.

-hiren