Hi Chris,
On 5/11/2020 12:13 pm, Chris Plummer wrote:
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).
Right, I can see all this from the caller context now - it is what was
set by 8214854. A comment to that affect would be good.
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.
I think that (compiler is wrong) is what was concluded the last time
this kind of warning came up (recently, not 8214854). We've sized the
buffer exactly as needed based on the components. I'm trying to find the
other bug related to this but I think we just silenced the warning in
that recent case.
Thanks,
David
-----
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
