On Fri, 6 Nov 2020 01:04:09 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> Apply patch suggested by @cl4es in the bug report. Passes
>> linux-x86-open,linux-x64-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
>> builds with this patch, and tier1.
>>
>> thanks,
>> Coleen
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Adjust millisecond format.
Some things are still unclear about this. My first calculation may have been a
bit off too.
The gcc error was this:
`log_messages.c:81:11: note: 'snprintf' output between 6 and 86 bytes into a
destination of size 81`
The maximum ("and 86 bytes") is not clear to me now:
First string: a buffer of DT_SIZE = 20
Third string: a buffer of TZ_SIZE = 57
I assume the compiler assumes that those strings are zero terminated. So first
string 19 chars max, third string 56 chars max.
Then, we have the %.3d - the max len of this is not 10, as I assumed, but 11:
if argument = INT_MIN = "-2147483647" = 11 chars.
The format string itself brings two characters.
So we have:
19 + 56 + 11 + 2 = 88.
Including terminating zero, we get 89.
So the compiler should complain about 89 characters put into the 81 character
buffer, not 86.
src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 84:
> 82: // Truncate milliseconds in buffer large enough to hold the
> 83: // value which is always < 1000 (and so a maximum of 3 digits for
> "%.3s")
> 84: char tmp[10 + 1];
I was wrong yesterday. Max len of %d would be 11 chars (if INT_MIN). Can you
make this buffer 11 chars please?
This error would have had no practical consequence: tmp[] would be filled to
the brim, leaving out the terminating zero, and since we then print with %.3s,
this would have had no negative effect)
-------------
Changes requested by stuefe (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1067
