On Thu, 22 Jun 2023 14:23:25 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: > > 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
