RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows

Brent Christian brent.christian at oracle.com
Tue May 12 18:24:00 UTC 2020


Thanks - change is pushed.  -B

On 5/11/20 5:26 PM, naoto.sato at oracle.com wrote:
> +1
> 
> Naoto
> 
> On 5/11/20 5:25 PM, Brian Burkhalter wrote:
>> Hi Brent,
>>
>> It looks OK to me.
>>
>> Brian
>>
>>> On May 11, 2020, at 4:36 PM, Brent Christian 
>>> <brent.christian at oracle.com> wrote:
>>>
>>> Please review this small fix in Windows native code:
>>>
>>>    Bug: https://bugs.openjdk.java.net/browse/JDK-8244767 
>>> <https://bugs.openjdk.java.net/browse/JDK-8244767>
>>> Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/ 
>>> <http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/>
>>>
>>> As reported on this thread[1], the getEncodingInternal() function has 
>>> a potential unterminated string in the case that the GetLocaleInfo() 
>>> Windows function fails.  In this case, the default switch() case will 
>>> write "Cp" to the beginning of the 'ret' buffer, but the rest of the 
>>> buffer remains uninitialized and unterminated.
>>>
>>> The fix is to strcpy() the default codepage into 'ret'.
>>


More information about the core-libs-dev mailing list