On 08/20/2018 08:25 PM, Jason Greene wrote: > >> On Aug 20, 2018, at 12:23 PM, Andrew Haley <a...@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
