This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/17136] New: [mingw/cygwin] Conflicting JNI function declarations
- From: "dannysmith at users dot sourceforge dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Aug 2004 10:06:11 -0000
- Subject: [Bug libgcj/17136] New: [mingw/cygwin] Conflicting JNI function declarations
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
This has been reported to Java list. Reporting here so it doesn't get lost.
While testing a patch to fix PR c++/15774 (Conflicting function decls
not diagnosed) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15774
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 -- although introduced by my sandbox patch -- are valid
complaints.
The friend declarations in the generated headers and in the provided
header, java/lang/Class.h lack the JNICALL (== __stdcall__) attribute
that is added in the function definitions 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.
In these specific cases in libjava, the definition is not visible, nor
is there any user-visible redeclaration with the stdcall attribute.
Although I do not have a specific testcase (my knowledge of java-land
reflection semantics is minimal) to demonstrate, this mismatch is very
likely to lead to stack corruption. (Failure to correctly prototype
win32api stdcall functions is always a prime suspect when stack
corruption bugs are reported in mingw-land).
A patch to add JNICALL to the declarations has been submitted at:
http://gcc.gnu.org/ml/java-patches/2004-q3/msg00456.html
Danny
--
Summary: [mingw/cygwin] Conflicting JNI function declarations
Product: gcc
Version: 3.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17136