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