So I'll implement a new native structure for BiDiWrapper to keep UBiDi and embedding levels pointers at the same place. And not disturb Java code at all.
SY, Alexey 2006/10/12, Paulex Yang <[EMAIL PROTECTED]>:
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]
-- 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]