RFR: 8308780: Fix the Java Integer types on Windows [v8]

[Daniel Jeliński]

On Thu, 22 Jun 2023 14:23:25 GMT, Julian Waters <jwaters at 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:
> 
>   GetDIBits should take an LPVOID

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:

> 1087:                 entry_point();
> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, (LPVOID) colorBits, &bmi, DIB_RGB_COLORS);

I don't believe casting to LPVOID was what @prrace was asking here.
The function takes a void* parameter because any other pointer type is implicitly convertible to that. We are using long/int/jint because we're asking for 32 bits per pixel (see biBitCount above); if we asked for 24/16/8/any other number of bits per pixel, we would have used a different pointer type.
Please revert these casts. They don't add any value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238616005