RFR: 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code
Kim Barrett
kbarrett at openjdk.org
Tue Jul 30 06:56:33 UTC 2024
On Tue, 30 Jul 2024 05:27:37 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Please review this change that removes some uses of literal 0 as a null
>> pointer constant in prims code.
>>
>> Testing: mach5 tier1
>
> src/hotspot/share/prims/jni.cpp line 1151:
>
>> 1149: \
>> 1150: EntryProbe; \
>> 1151: ResultType ret{}; \
>
> This looks bogus. ResultType is just a macro variable and could be a primitive type. ?? Does the local need initializing?
This is value-initialization syntax. Value-initialization of a primitive type is zero-initialization.
However, I think we don't need the local variable at all. Here and in the other 5(?) similar places, rather than
ResultType ret{};
...
ret = jvalue.get_##ResultType();
return ret;
I think we could just have
...
return jvalue.get_##ResultType();
> src/hotspot/share/prims/methodHandles.cpp line 439:
>
>> 437: default:
>> 438: fatal("unexpected intrinsic id: %d %s", vmIntrinsics::as_int(iid), vmIntrinsics::name_at(iid));
>> 439: return 0;
>
> Do we no longer need these returns after `fatal` to keep compilers happy?
Now that we have, and are using, `[[noreturn]]` on all platforms, we no longer need that dead code.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408217
PR Review Comment: https://git.openjdk.org/jdk/pull/20385#discussion_r1696408335
More information about the serviceability-dev
mailing list