jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean

[Baesken, Matthias]

Hi Phil,  thanks for  clarifying !

Then just one  function remains,  the coding of  VerifyClassForMajorVersion   in   check_code.c ,  where  we  leave the range  of JNI_TRUE / JNI_FALSE :

we might assign "result = context->err_code;"
and err_code  gets potentially  values  0 - 3  

--------------------------------------------------------------------------------------------------------------------------------
jdk/src/java.base/share/native/libverify/check_code.c


763#define CC_OK 1
764#define CC_VerifyError 0
765#define CC_OutOfMemory 2
766#define CC_ClassFormatError 3
767
768JNIEXPORT jboolean
769VerifyClassForMajorVersion(JNIEnv *env, jclass cb, char *buffer, jint len,
770                           jint major_version)
771{
.................
774    jboolean result = CC_OK;
775    int i;
776    int num_methods;
777    int* code_lengths;
778    unsigned char** code;
779

878        result = CC_OK;
879    } else {
880        result = context->err_code;
881    }

908    return result;
909}
910

Best regards, Matthias





> -----Original Message-----
> From: Phil Race <philip.race at oracle.com>
> Sent: Freitag, 28. September 2018 18:33
> To: Andrew Haley <aph at redhat.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; jdk-dev at openjdk.java.net
> Cc: Simonis, Volker <volker.simonis at sap.com>
> Subject: Re: jboolean handling in native JDK code - was : RE: 8211163: UNIX
> version of Java_java_io_Console_echo does not return a clean boolean
> 
> _RequestWindowFocus is declared to return jboolean.
> 
> So I don't think there's a nasty bug, just a whole lot of casting which might
> be better avoided by some additional overload of SyncCall() which accepts
> the function's real signature.
> 
> -phil.
> 
> 
> On 09/28/2018 07:04 AM, Andrew Haley wrote:
> > On 09/28/2018 01:32 PM, Baesken, Matthias wrote:
> >> Shouldn't we better compare  the  pointer to NULL   instead of just
> casting ?
> > Heavens, yes! You have found a nasty bug.
> >
> > Note that the cast to intptr_t used here suppresses the compiler
> > warning which should have been a big clue that something was
> > wrong. Good catch.
> >
> > 8198895: Compilation errors in java.desktop with VS 2017
> >
> > +++
> b/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp
> Mon Mar 19 14:16:23 2018 -0700
> > @@ -3915,8 +3915,8 @@
> >       rfs->component = selfGlobalRef;
> >       rfs->isMouseEventCause = isMouseEventCause;
> >
> > -    return (jboolean)AwtToolkit::GetInstance().SyncCall(
> > -        (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs);
> > +    return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall(
> > +        (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs));
> >       // global refs and rfs are deleted in _RequestWindowFocus
> >
> >       CATCH_BAD_ALLOC_RET(JNI_FALSE);