Re: JNI bug?

[Andrew Haley <aph at redhat dot com>]

Andrew Haley writes:
 > Marco Trudel writes:
 >  > Hey all
 >  > 
 >  > Here's an interesting one where GCJ sometimes isn't doing the same as a 
 >  > Sun JDK (no no Andrew, don't stop reading ;-)). Check out this little 
 >  > Java class:
 >  > 
 >  > public class NativeBooleanTest
 >  > {
 >  > 	public static void main(String[] args)
 >  > 	{
 >  > 		System.loadLibrary("nativeBoolean");
 >  > 		nativePrintBoolean(false);
 >  > 		nativePrintBooleanAsInt(false);
 >  > 	}
 >  > 	
 >  > 	private static native void nativePrintBoolean(boolean b);
 >  > 	private static native void nativePrintBooleanAsInt(boolean b);
 >  > }
 >  > 
 >  > Now this c code:
 >  > 
 >  > #include <jni.h>
 >  > 
 >  > JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBoolean
 >  > 	(JNIEnv *env, jclass c, jboolean b)
 >  > {
 >  > 	printf("nativePrintBoolean: %d\n", b);
 >  > }
 >  > 
 >  > JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBooleanAsInt
 >  > 	(JNIEnv *env, jclass c, jint b)
 >  > {
 >  > 	printf("nativePrintBooleanAsInt: %d\n", b);
 >  > }
 >  > 
 >  > 
 >  > On a sun JVM, the output will be:
 >  > nativePrintBoolean: 0
 >  > nativePrintBooleanAsInt: 0
 >  > 
 >  > On GCJ, in this minimalistic sample, it will always be:
 >  > nativePrintBoolean: 0
 >  > nativePrintBooleanAsInt: 10084864
 >  > 
 >  > In a huge library I debugged for this, GCJ 4.3 gives twice 0 if 
 >  > optimization is disabled and also "10084864" as soon as optimization is 
 >  > enabled. GCJ 4.2 gives twice 0 in -O3 mode, GCJ 4.3 no longer.
 >  > 
 >  > 
 >  > So,what do others think? What is the problem? Should there be an 
 >  > implicit cast? Is the code wrong? If yes, should it be attended so that 
 >  > the Sun RE is met?
 >  > Unfortunately, this seems to go into the same unpleasant RE topic as my 
 >  > Arrays patch... But it also might be a GCJ bug. I don't know for sure.

Err, *why* are you doing this weird thing, anyway?  Why not pass the correct type?

Andrew.