Alexey Petrenko wrote:
> In fact the most interesting question: can ubidi_getLevels return
> another pointer or not? If there is such possibility then we need to
> store original pointer somewhere.
Yes, there is such possibility. If I understand correctly, in case Oleg
just mentioned, a new level array will be created and returned by
ubidi_getLevels, although I'm not ICU4C guru:).
IMO, the original pointer should be kept by the application using ICU4C,
because the ubidi API document doesn't gurantee that the ubidi_getLevels
will return the embeddinglevel from setPara(), but it does requires the
application to take care of that embeddinglevel's life
cycle(allocate/deallocate), so it is safer to keep this pointer
somewhere.
>
> 2006/10/12, Oleg Khaschansky <[EMAIL PROTECTED]>:
>> What exactly your code is? It, probably, may rearrange the levels if
>> you didn't explicitely set them for all the characters including
>> trailing whitespace. If this is the case it may add some additional
>> levels and relocate the array. Could you check if the size of the
>> array changed?
>>
>> On 10/12/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> > Is any ICU4C gurus here?
>> >
>> > I'm setting an embedding levels pointer with ubidi_setPara
method. And
>> > it seems that ubidi_getLevels returns not the same pointer.
>> >
>> > Is this correct feeling or am I doing something wrong?
>> >
>> > SY, Alexey
>> >
>> >
>> > 2006/10/11, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>:
>> > > [
>>
http://issues.apache.org/jira/browse/HARMONY-100?page=comments#action_12441378
>> ]
>> > >
>> > > Alexey Petrenko commented on HARMONY-100:
>> > > -----------------------------------------
>> > >
>> > > I agree with Tim's suggestion and will create a patch.
>> > >
>> > > > text/BidiWrapper issue?
>> > > > -----------------------
>> > > >
>> > > > Key: HARMONY-100
>> > > > URL:
>> http://issues.apache.org/jira/browse/HARMONY-100
>> > > > Project: Harmony
>> > > > Issue Type: Bug
>> > > > Components: Classlib
>> > > > Reporter: Vladimir Gorr
>> > > >
>> > > > Let's consider the following test:
>> > > > import java.text.Bidi;
>> > > > public class Test {
>> > > > public static void main(String[] args) throws Exception {
>> > > > Bidi bd = new Bidi(new char[] { 's', 's', 's'
}, 0,
>> > > > new byte[] { (byte) -7, (byte)
>> -2, (byte) -3 },
>> > > > 0, 3,
>> Bidi.DIRECTION_DEFAULT_LEFT_TO_RIGHT);
>> > > > System.out.println("Expected 7, real " + " "
>> + bd.getLevelAt(0));
>> > > > }
>> > > > }
>> > > > In my opinion the JNI implementation of Bidi
>> (text/BidiWrapper.c file, ubidi_1setPara() function) contains a
>> potential bug, namely:
>> > > > 1. If the embeddingLevels argument is not NULL then
>> _embeddingLevels variable is initialized with the JNI
>> GetByteArrayElements() function;
>> > > > 2. ICU function (ubidi_setPara) initializes ICU inner structure
>> and puts the _embeddingLevels into it;
>> > > > 3. If _embeddingLevels pointer is not NULL then the JNI
>> ReleaseByteArrayElements() function (with 0 as fourth parameter) is
>> called.
>> > > > This function releases the memory (according to JNI
>> specification) the _embeddingLevels pointer refers to;
>> > > > 4. After that ICU inner structure isn't initialized properly.
>> Call of ICU ubidi_getLevels() function can return incorrect values
>> (see java test above).
>> > > > It seems the JNI_COMMIT parameter instead of "0" should be
>> passed to the ReleaseByteArrayElements() to avoid this problem.
>> > > > I'd like to underline the test mentioned above works w/o any
>> issues for Harmony-14 contribution (although it shouldn't sometimes
>> IMHO).
>> > > > Therefore if there are any doubts in my argumentation this
>> issue can be closed as invalid.
>> > >
>> > > --
>> > > This message is automatically generated by JIRA.
>> > > -
>> > > If you think it was sent incorrectly contact one of the
>> administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
>> > > -
>> > > For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Alexey A. Petrenko
>> > Intel Middleware Products Division
>> >
>> >
---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> > For additional commands, e-mail:
[EMAIL PROTECTED]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
