Is returning a value != '0' or '1' as jboolean from a JNI function legal? (original) (raw)

Andrew Haley aph at redhat.com
Tue Aug 21 13:23:32 UTC 2018


On 08/20/2018 08:25 PM, Jason Greene wrote:

On Aug 20, 2018, at 12:23 PM, Andrew Haley <aph at redhat.com> wrote:

On 08/20/2018 04:14 PM, Jason Greene wrote:

IMO departing from C semantics (non-zero = TRUE, zero = false) offers little gain and will likely just lead to hard to catch bugs. Even if the JNI developer knows the rules, it will be quite easy for surprises to show up. For example, a developer might assume a library call always returns 1, and wire it straight to a boolean. If this assumption is broken (a condition not taken into account, or future behavioral differences), then it could quickly turn into a lot of wasted time and effort. It's tricky, though: a C implementation could silently truncate a value of 0xff000000 to (jboolean) 0x00, and there's not a damn thing that a JVM can do about it: there's literally no way to know. It's pretty much unfixable from our end. OK but in that case the C developer can see its an unsigned char,

It's a jboolean.

and their compiler is likely to throw an overflow warning.

Mmm, but GCC desn't.

Granted, it’s also true that int is a more common return value than unsigned char.

The function in question is defined as returning a jboolean: there's no doubt about that. The question is whether a C implementation truncates return values, and you can only see that by reading the system ABI specification. Not every system documents it: the only way until recently to find out what GCC on x86 did was to look at the generated code.

The system ABI is different on different systems: on AArch64 a jboolean return value is silently truncated, on x86 it isn't. The only solution is to do what's suggested: make sure that you return JNI_TRUE/JNI_FALSE (or 1/0).

It's all too horrible even to think about.

-- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the core-libs-dev mailing list