On Thu, 5 Nov 2020 17:57:29 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>>> While it's possible that these warnings on 32-bit builds is just a matter
>>> of the compiler being wrong, it could also be that it can't determine all
>>> arguments are null-terminated. Specifying max string length in format
>>> specifiers seem a benign and cheap safeguard.
>>
>> I don't think this is the case. If you assume the arguments are not null
>> terminated, then there is no limit to how long the string could be, where-as
>> the error messages are very specific with the (incorrectly) calculated range
>> of potential overflow.
>
>> I don't think this is the case. If you assume the arguments are not null
>> terminated, then there is no limit to how long the string could be, where-as
>> the error messages are very specific with the (incorrectly) calculated range
>> of potential overflow.
>
> I must be missing what you're suggesting here?
Hi,
I think the compiler is correct. The 3 in "%.3d" of the second argument is
precision, not scale. Which is the *minimum* numbers of digits to be printed.
So we get:
(void)snprintf(tbuf, ltbuf,
"%s.%.3d %s", timestamp_date_time,
(int)(millisecs), timestamp_timezone);
with timestamp_date_time = DT_SIZE = 20 and timestamp_timezone = TZ_SIZE = 56
and the second argument prints at least three digits but possibly more if the
argument is longer. MAX_INT is 2147483647. So length could be 10.
56 + 20 + 10 = 86.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1067
