Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6175065

javasoft.sqe.tests.api.java.text.Bidi.ctorTests revealing invalid platform assumptions in J2SE code

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: P2 P2
    • 6
    • 1.4a
    • core-libs
    • generic
    • generic

      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

            dougfelt Doug Felt (Inactive)
            clucasius Carlos Lucasius (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: