On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwat...@openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 
>> respectively. In particular, the former is rather problematic since it 
>> breaks compilation as the Visual C++ becomes stricter and more compliant 
>> with every release, which means the way Windows code treats long as a 
>> typedef for int is no longer correct, especially with -permissive- enabled. 
>> Instead of changing every piece of broken code to match the jint = long 
>> typedef, which is far too time consuming, we can instead change jint to an 
>> int (which is still the same 32 bit number type as long), as there are far 
>> fewer problems caused by this definition. It's better to get this over and 
>> done with sooner than later when a future version of Visual C++ finally 
>> starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix the code that is actually warning

Compilation should be a good enough test for the `long` -> `jint` changes. 
These changes are supposed to address [this 
difference](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments)
 between MSVC behavior and the C++ standard. When compiled with `-permissive-` 
or with a compiler that puts more emphasis on standards conformance (like 
clang), the current code fails to compile.

I verified some of the generated binaries by comparing the results of `dumpbin 
/all` before and after the change. Most of the time the changes were limited to 
timestamp, UUID and mangled function names. `Jaccesswalker.exe` had a few more 
changes because of a changed format string. None of the changed function names 
in client libs area are externally visible, but there are some observable 
changes to `c2v` functions exported from jvm.dll.

I had to revert some of the `NULL`->`nullptr` changes to get this to compile; I 
assume this will be addressed before this PR is merged. Judging by the PR 
title, these changes don't belong here anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600710570

Reply via email to