RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

[David Holmes]

On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt <mikael at 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}

src/java.base/share/native/libverify/check_code.c line 4168:

> 4166: }
> 4167: 
> 4168: static void check_and_push_const(context_type *context, const void *ptr, int kind) {

IIUC the only `const` cases all pass a `const char*` so perhaps we can make that explicit in the signature? I confess I can't figure out how the passed in memory eventually gets used and it seems bizarre that it could be a freshly malloc'd block or an existing string.

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

PR: https://git.openjdk.java.net/jdk/pull/7794