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
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:
<!--#yiv1172509327 _filtered {} _filtered {} _filtered {} _filtered {}#yiv1172509327 #yiv1172509327 p.yiv1172509327MsoNormal, #yiv1172509327 li.yiv1172509327MsoNormal, #yiv1172509327 div.yiv1172509327MsoNormal {margin:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv1172509327 span.yiv1172509327EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv1172509327 .yiv1172509327MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv1172509327 div.yiv1172509327WordSection1 {}--> 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
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.commailto: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.orgmailto: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.orgmailto: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
tf-a@lists.trustedfirmware.org
-
Hiren Mehta -
Varun Wadekar