On Thu, 5 Nov 2020 02:11:23 GMT, Chris Plummer <cjplum...@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. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1067
