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