RFR: 8254270: linux 32 bit build doesn't compile libjdwp/log_messages.c [v4]

[Thomas Stuefe]

On Fri, 6 Nov 2020 01:04:09 GMT, Coleen Phillimore <coleenp at 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