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

[Claes Redestad]

On Thu, 5 Nov 2020 09:12:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Where did the magic numbers in
>>> 
>>> "%.19s.%.3d %.50s"
>>> 
>>> come from?
>> 
>> The first argument is a char[DT_SIZE], which is MAXLEN_DT+1, which is 20. The +1 is probably for a null. The 3rd argument is char[TZ_SIZE], which is TIMESTAMP_SIZE - MAXLEN_DT - MAXLEN_MS, which is 81 -19 - 5, which is 56. The target buffer is char[MAXLEN_TIMESTAMP+1], which is 81 (and so is ltbuf). So without any of Coleen's changes we are writing at most 19 + 3 + 1 + 56 + 1 bytes, which is 80 bytes, into an 81 byte buffer. The compiler should not be complaining here. 
>> 
>> And just to clarify, the compiler DOES see the size of the destination buffer. It's looking at the source of the argument passed in. However, it seems to have computed some lengths incorrectly and came to the conclusion that the buffer might not be big enough to handle the known sizes of all the snprintf arguments.
>
> Please make sure `linux-x86` jobs pass in GH actions. I think you can navigate to https://github.com/coleenp/jdk/runs/1355854648 -- and press "Re-run jobs" at top right.

FWIW I don't think I intended the workaround of specifying limits to be patched in as-is, although it seems benign to go ahead and do this. 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1067