From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20509 invoked by alias); 22 Aug 2004 10:06:13 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 20469 invoked by uid 48); 22 Aug 2004 10:06:11 -0000 Date: Sun, 22 Aug 2004 10:06:00 -0000 From: "dannysmith at users dot sourceforge dot net" To: java-prs@gcc.gnu.org Message-ID: <20040822100552.17136.dannysmith@users.sourceforge.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/17136] New: [mingw/cygwin] Conflicting JNI function declarations X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00305.txt.bz2 List-Id: 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