On Thu, 5 Nov 2020 09:12:54 GMT, Aleksey Shipilev <sh...@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
