This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Conflicting JNI function decls
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: java at gcc dot gnu dot org
- Date: Sat, 31 Jul 2004 12:59:25 +1200
- Subject: Conflicting JNI function decls
- Reply-to: Danny Smith <dannysmith at users dot sourceforge dot net>
Hi,
While testing a patch to fix PR c ++/15774 (Conflicting function decls
not diagnosed) I get this in libjava build.
../../../gcc/libjava/jni.cc:
In function `java::lang::Object* _Jv_JNI_ToReflectedField(JNIEnv*,
java::lang::Class*, _Jv_Field*, jboolean)'
: ../../../gcc/libjava/jni.cc:1612: error: new declaration
`java::lang::Object* _Jv_JNI_ToReflectedField(JNIEnv*,
java::lang::Class*, _Jv_Field*, jboolean)'
./java/lang/reflect/Field.h:70: error: ambiguates old declaration
`java::lang::Object* _Jv_JNI_ToReflectedField(_Jv_JNIEnv*,
java::lang::Class*, _Jv_Field*, jboolean)'
../../../gcc/libjava/jni.cc:
In function `java::lang::Object* _Jv_JNI_ToReflectedMethod(JNIEnv*,
java::lang::Class*, _Jv_Method*, jboolean)':
../../../gcc/libjava/jni.cc:1643: error: new declaration
`java::lang::Object* _Jv_JNI_ToReflectedMethod(JNIEnv*,
java::lang::Class*, _Jv_Method*, jboolean)'
./java/lang/reflect/Method.h:40: error: ambiguates old declaration
`java::lang::Object* _Jv_JNI_ToReflectedMethod(_Jv_JNIEnv*,
java::lang::Class*, _Jv_Method*, jboolean)' make[2]: *** [jni.lo] Error
These errors -- introduced by my sandbox patch -- are valid complaints.
The friend declarations in the generated headers lack the JNICALL (==
__stdcall__) attribute that are added in the definition in jni.cc. In
general, this is dangerous, even if the definition is visible or if the
function is later redeclared with the attribute, since the function may
be
referenced (without the attribute) before the attribute is added.
For stdcall vs non-stdcall mismatch this means stack corruption.
Perhaps, everything "just works" now .It seems that some of these are
also defined as extern inline (without attribute) in headers in the gcj
directory and so calling convention may be a non-issue. But to be safe
this kind of ambiguity needs to be avoided, Similar ambiguity has lead
to all sorts of hard-to-diagnose problems with another attribute
(dllimport) on windows targets
Danny