SHORT-DESCRIPTION:
-----------------
The existing code for the offending tests (see attached .jtr file) doesn't work
on platforms that aren't utilizing 8-bit bytes and 2's-complement arithmetic.
Just to summarize the key points about the invalid platform assumptions being
made by these tests:
1) A signed value is being placed into an unsigned field.
2) The code assumes that the most significant bit for a char type is 0x80.
3) The code assumes that the least significant bit is set for both positive and negative odd values.
LONG-DESCRIPTION:
----------------
We have some questions as the result of our investigation of one of the
api/java_text tests that fails
(javasoft.sqe.tests.api.java.text.Bidi.ctorTests).
When a new instance of BiDi is created, the second parameter to the constructor
is an int field that can possibly be a negative number. The constructor in
BiDi.java looks as follows:
public Bidi(String paragraph, int flags)
Some of the possible values passed as the 2nd parameter are:
public static final int DIRECTION_DEFAULT_LEFT_TO_RIGHT = -2;
public static final int DIRECTION_DEFAULT_RIGHT_TO_LEFT = -1;
The int field flags is passed to native code (jbidi.c) as a jint (still
retains the sign). It is passed as the last parameter (dir) as follows:
JNIEXPORT void JNICALL Java_java_text_Bidi_nativeBidiChars
(JNIEnv *env, jclass cls, jobject jbidi, jcharArray text, jint tStart, jbyteArray embs, jint eStart, jint length, jint dir)
The following line then casts the int field dir to an unsigned char:
UBiDiLevel baseLevel = (UBiDiLevel)dir;
Why is a signed field being cast to an unsigned field?
The routine ubidi_setPara (ubidi.c) is then called passing this unsigned
field:
ubidi_setPara(bidi, cText + tStart, length, baseLevel, cEmbsAdj, &err);
The routine ubidi_setPara does numeric comparisons on this unsigned char field
(paraLevel):
if(pBiDi==NULL || text==NULL ||
(UBIDI_MAX_EXPLICIT_LEVEL<paraLevel) && !IS_DEFAULT_LEVEL(paraLevel) ||
length<-1
Why are numeric comparisons being done on this unsigned field? In addition,
the IS_DEFAULT_LEVEL macro is doing some bit manipulation that would only
appear to work on platforms with 8-bit bytes and 2's complement arithmetic.
###@###.### 10/6/04 19:06 GMT
-----------------
The existing code for the offending tests (see attached .jtr file) doesn't work
on platforms that aren't utilizing 8-bit bytes and 2's-complement arithmetic.
Just to summarize the key points about the invalid platform assumptions being
made by these tests:
1) A signed value is being placed into an unsigned field.
2) The code assumes that the most significant bit for a char type is 0x80.
3) The code assumes that the least significant bit is set for both positive and negative odd values.
LONG-DESCRIPTION:
----------------
We have some questions as the result of our investigation of one of the
api/java_text tests that fails
(javasoft.sqe.tests.api.java.text.Bidi.ctorTests).
When a new instance of BiDi is created, the second parameter to the constructor
is an int field that can possibly be a negative number. The constructor in
BiDi.java looks as follows:
public Bidi(String paragraph, int flags)
Some of the possible values passed as the 2nd parameter are:
public static final int DIRECTION_DEFAULT_LEFT_TO_RIGHT = -2;
public static final int DIRECTION_DEFAULT_RIGHT_TO_LEFT = -1;
The int field flags is passed to native code (jbidi.c) as a jint (still
retains the sign). It is passed as the last parameter (dir) as follows:
JNIEXPORT void JNICALL Java_java_text_Bidi_nativeBidiChars
(JNIEnv *env, jclass cls, jobject jbidi, jcharArray text, jint tStart, jbyteArray embs, jint eStart, jint length, jint dir)
The following line then casts the int field dir to an unsigned char:
UBiDiLevel baseLevel = (UBiDiLevel)dir;
Why is a signed field being cast to an unsigned field?
The routine ubidi_setPara (ubidi.c) is then called passing this unsigned
field:
ubidi_setPara(bidi, cText + tStart, length, baseLevel, cEmbsAdj, &err);
The routine ubidi_setPara does numeric comparisons on this unsigned char field
(paraLevel):
if(pBiDi==NULL || text==NULL ||
(UBIDI_MAX_EXPLICIT_LEVEL<paraLevel) && !IS_DEFAULT_LEVEL(paraLevel) ||
length<-1
Why are numeric comparisons being done on this unsigned field? In addition,
the IS_DEFAULT_LEVEL macro is doing some bit manipulation that would only
appear to work on platforms with 8-bit bytes and 2's complement arithmetic.
###@###.### 10/6/04 19:06 GMT