JDK-8226810: An other case and a small change suggestion

[Alan Bateman]

On 10/05/2020 15:47, Johannes Kuhn wrote:
> :
>
> After the discussion with Naoto, I would like to change the one line 
> to strcpy(ret + 2, "1252")
>
> diff --git a/src/java.base/windows/native/libjava/java_props_md.c 
> b/src/java.base/windows/native/libjava/java_props_md.c
> --- a/src/java.base/windows/native/libjava/java_props_md.c
> +++ b/src/java.base/windows/native/libjava/java_props_md.c
> @@ -73,6 +73,7 @@
>                        LOCALE_IDEFAULTANSICODEPAGE,
>                        ret+2, 14) == 0) {
>          codepage = 1252;
> +        strcpy(ret + 2, "1252");
>      } else {
>          codepage = atoi(ret+2);
>      }
>
> I have already signed the OCA.
> This would be my first patch. Is there anything else you need?
>
> I will take a further look into GetLocaleInfo, and try to find a model 
> that works for me (currently thinking about blackbox, can return 
> anything from [1]),
> and then discussing how to handle all those cases.
It's not clear how conditions are necessary for GetLocaleInfo to fail 
but good to fix this code path. We should probably create a new issue in 
JIRA for this as it's not clear that it is the same issue as 
JDK-8226810. We've been chasing JDK-8226810 for some time but have not 
been able to find a system where it duplicates. The reports so far 
suggests is Windows Chinese but most of the people that report the issue 
to not respond to questions so we can't be sure. One of the reports (see 
my comment in the bug from June 2019) suggests the code page is 54936, 
useful information as GB18030 is not in java.base. Once your fix is in 
then I think we should try to improve the exception message rather than 
NPE. There may be some of these cases where it should default to UTF-8.

-Alan.