On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt <mik...@openjdk.org> wrote:
> Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function > 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may > be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument > 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, > int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes > that the malloc:ed data, which has not yet been initialized, will not be/can > not be modified later which in turn suggests it may be used without ever > being initialized. > > The same general issue was addressed in > [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably > for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc > attributes I chose to change the check_and_push function to take a > (non-const) void* argument, and provide a new wrapper function > `check_and_push_const` which handles the const argument case. For the > (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a > const conversion. > > To avoid having multiple ways of solving the same problem I also chose to > revert the change made in JDK-8266168, reverting the calloc back to a malloc > call. > > Testing: > > tier1 + builds-tier{2,3,4,5} This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794
