Re: error: 'jvariant::jvariant(jbyte)' cannot be overloaded

Andrew Haley <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>
On 07/19/2009 09:17 AM, Florian Weimer wrote:
> * Andrew Haley:
> 
>> On 07/19/2009 07:02 AM, Florian Weimer wrote:
>>> * Mathieu Malaterre:
>>>
>>>>   I am trying to compile VTK using gcj and I am getting those compiler
>>>> error, could someone please let me know if the code is legal (should
>>>> compile) or not:
>>> This is legal per Sun's JNI specficiation: jboolean and jbyte are
>>> distinct types because there signedness differs:
>>>
>>> <http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/types.html#wp198>
>>>
>>> It's a bug in GCC.
>> I didn't see the original message to which this is replying.
> 
> It's about C++ code which contains a function overloaded on jbyte and
> jboolean.  This fails with GCJ because they are typedef'ed to the same
> type.
> 
>> If you can make a test case I'll see if the bug can be fixed.
> 
> Compare the table I referenced with these pieces from jni_md.h:
> 
> | typedef int    jbyte  __attribute__((__mode__(__QI__)));
> | typedef int    jshort __attribute__((__mode__(__HI__)));
> | typedef int    jint   __attribute__((__mode__(__SI__)));
> | typedef int    jlong  __attribute__((__mode__(__DI__)));
> | typedef int    jboolean __attribute__((__mode__(__QI__)));
> | typedef unsigned short jchar __attribute__((__mode__(__HI__)));
> | typedef float  jfloat;
> | typedef double jdouble;
> | typedef jint jsize;
> 
> | typedef int8_t jbyte;
> | typedef int16_t jshort;
> | typedef int32_t jint;
> | typedef int64_t jlong;
> | typedef float jfloat;
> | typedef double jdouble;
> | typedef jint jsize;
> | typedef int8_t jboolean;
> | typedef uint16_t jchar;
> 
> jboolean is signed, but Sun's spec says it should be unsigned.

OK.  I can fix it, but it's an ABI-incompatible change.  There's no
way this fix could be applied to any existing releases, only gcc
4.5.

Andrew.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.