On Thu, 5 Nov 2020 00:37:15 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 > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1067
