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

[Xueming Shen]

On 08/17/2018 10:25 AM, Aleksey Shipilev wrote:
> On 08/17/2018 05:12 PM, Volker Simonis wrote:
>> The offending code in Console_md.c looks as follows:
>>
>> #define ECHO    8
>>
>> JNIEXPORT jboolean JNICALL
>> Java_java_io_Console_echo(...) {
>>
>>      jboolean old;
>>      ...
>>      old = (tio.c_lflag&  ECHO);
>>      ...
>>      return old;
>> }
>>
>> The intention of this code is to return "true" if the ECHO flag was
>> set but it really returns the value of ECHO (which is defined as '8'
>> in a system header).
>>
>> The question now is, if a Java SE compatible VM guarantees that any
>> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE"
>> and only a zero valued jboolean will be interpreted as "JNI_FALSE"?
>>
>> Or, the other way round, is the normalization performed by the HotSpot
>> result handlers necessary (i.e. enforced by the specification) or just
>> a convenience to fix broken code like the above from Console.echo()?
> I think this is intentional aftermath of boolean value normalization:
>    https://bugs.openjdk.java.net/browse/JDK-8161720
>
> So, Java_java_io_Console_echo looks broken and needs to be fixed, by e.g.:
>
> -   old = (tio.c_lflag&  ECHO);
> +   old = (tio.c_lflag&  ECHO) != 0;
>
> Thanks,
> -Aleksey
>

Yes, the code in Console_md.c need/will be updated to fix this issue. We planed and
tried in early circle of jdk11 when working on 8194750, at least for the newly added
code.  But change had been backed out for other reason. Will fix this specific one in
12. But the existing code is about decade old, I would assume you probably still need
to fix the s390x part as a "regression".

Thanks!
Sherman