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