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

David Holmes david.holmes at oracle.com
Thu Nov 5 02:44:28 UTC 2020


Hi Chris,

On 5/11/2020 12:13 pm, Chris Plummer wrote:
> On Thu, 5 Nov 2020 00:37:15 GMT, Coleen Phillimore <coleenp at 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
> 


More information about the serviceability-dev mailing list