Opened 11 years ago

Last modified 11 years ago

#218 new defect

define jbyte as signed char

Reported by: Yuri Dario Owned by:
Priority: major Milestone: GA6
Component: general Version: 1.6.0 Build 27 GA5
Severity: high Keywords:
Cc:

Description (last modified by dmik)

In the OS/2 sdk, jni_mh.h defines the following types:

#ifdef __GNUC__
typedef int jint;
typedef __int64_t jlong;
typedef char jbyte;
#else
typedef long jint;
typedef __int64 jlong;
typedef signed char jbyte;
#endif

but the GNUC defines are different from default ones on other platforms.

When building Apache OpenOffice?, errors are issued because there isn't a direct cast from signed char to char, even if signed char is the default setting (they are treated as different types).

Change History (2)

comment:1 Changed 11 years ago by dmik

Description: modified (diff)

Corrected your description. It contained a wrong excerpt, probably the one you have already fixed (instead of the original one). Also, please don't forget to use and when pasting code samples here, otherwise formatting gets broken.

comment:2 Changed 11 years ago by dmik

Regarding the matter. I used signed char instead of just char for jbyte to make it compatible with char arrays used everywhere in the C/C++ code in Hotspot/JDK (which saved me from many warnings and sometimes from errors), see r329. On Windows such a difference is not a problem since MSVC ignores it.

However, I didn't notice that on *nix platforms it's also defined as signed char. But GCC compiler is used there as well, this means they somehow solve this difference problem. Quick search through the sources shows that they simply use C-style casts, like (char *) jbytebuf or (jbyte *) charbuf - the thing that I wanted to avoid.

Anyway, given that jbyte is signed char on all platforms but OS/2, for the sake of compatibility I give up. I will have to change it to signed char and fix all casting warnings/errors manually as described above. This ticket will track the task.

Note: See TracTickets for help on using tickets.