On Sat, 16 Dec 2023 06:38:38 GMT, Sam James <d...@openjdk.org> wrote:
> My preference for moving forward is: > > 1. I add some static_assert for off_t to the modified JVM bits to be safe > (that's what I tested with); > 2. We keep this PR for the build-only fixes which are semantically identical > to the previous code - this PR currently "preserves" bitness, it doesn't fix > anything other than avoiding use of foo64() where it's unnecessary by > converting to foo, but the foo64() use was right - just a glibcism - until > now. From what I can tell, the JVM code touched here was correct, just > relying on glibcisms; > 3. In another PR, we look at the general 32-bit LFS situation which may > involve runtime fixes if - as it appears - off_t is actually 32-bit on x86 > systems right now and non foo64() functions are being used. Then we either > port more stuff to use foo64() (not ideal), or consistently use foo() in more > places with FILE_OFFSET_BITS. I'm unclear how the current PR is expected to proceed under this plan. Does # 2 also keep the source code changes in this PR? Should the asserts from # 1 also be added to this PR? This issue is now hitting hard on Alpine Linux 3.19 - see [JDK-8324153](https://bugs.openjdk.org/browse/JDK-8324153) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1899810531
