JNI bug?

Mon Jan 29 18:15:00 GMT 2007

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.