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

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 0xff00_0000 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