RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

[Jie Fu]

On Thu, 30 Sep 2021 10:01:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some misc remarks from a build PoV:
> 
> * We count language and region settings as a build environment requirement, not a portability issue.
> * It is really a shame that Microsoft is making changes to these so darned hard. On all other platforms, LC_ALL=C in the make file just fixes the problem. :-(
> * But we do want the JDK to be easy to build, so this means that we might need to support building on more than en_US on Windows, at least until Microsoft get's their act together.
> 
> From what I see in the discussion here there seems to be no clarity in what range of character the specification allows. This needs to be absolutely clear for any changes here -- we can't filter out legal characters just because they are problematic to build on non en_US platforms.
> 
> However, I'm thinking that you need to take a step back and see what you are really trying to solve. To me, it seems that sscanf is not the right tool for the job, and the fact that it has worked until now is more a lucky coincidence. It seems, from a quick glance, that you should consider the input a byte array, and process it like that, instead of a string, if the encoding is unclear, and the spec is talking about character values (like 0x7f) rather than what characters they are supposed to represent in a specific encoding.

Thanks @magicus .

The background is that we want to build CI/CD pipelines for Windows platforms to help the OpenJDK development.

We already have enough Linux and MacOS pipelines but still not have one for Windows.
So we just plan to setup some Windows pipelines to further improve OpenJDK product quality.

But to my surprise, OpenJDK fails to build on our Windows platforms.

You may suggest changing the locale settings.
But many of our Apps don't allow us to changet it since we are non-English speaking country.
It's unfortunate that OpenJDK can't build on our Windows platforms.

It's not our goal to make CompileCommand work with non-ASCII chars.
If it doesn't make anything worse, we can just remove the non-ASCII code to make it to be more portable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5704