On Fri, 18 Mar 2022 02:39:23 GMT, Mikael Vidstedt <[email protected]> wrote:
>> Note: this PR replaces the one I messed up earlier.
>>
>> 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, 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}
>
> Mikael Vidstedt has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Use const char for check_and_push_string_utf
Looks good!
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7859
