On 01 Dec 2002 12:50:38 +0000, Mikhael Goikhman wrote: > > On 01 Dec 2002 01:04:09 +0100, Olivier Chapuis wrote: > > > > Ok, I've found the problem. FBidiConvert assume that the "in" string > > and the "out" string have the same length. This is the case until you > > joint. With joint what may happen is: > > > > UTF-8 src string have length 34 (as char *) > > --> convert into UCS-4, the string has length 20 (as char32 *) > > --> apply bidi algo, the string has length 20 (as char32 *) > > --> apply joint algo, the string has length 20 (as char32 *) > > --> convert back to UTF-8, the string has length 40 (as char *) > > > > ----> core dump > > > > the length of the returned string (visual_str) should be computed > > after the joint algo is performed. BTW, fribidi should know the length > > of the result of fribidi_unicode_to_charset before you call it, this > > is a very very strange way to implement a converter!! > > I think it should only know the length of the input (not sure why this is > needed, maybe to double check or to limit to the substring), not the > length of the output, which it returns.
Ah, I see now what you mean. Yes, fribidi assumes the caller allocate the space for the output, that is just an incorrect thing to do for such library, because a caller can't know the output length yet. > > So we need the function: > > > > USC4UTF8Length(Char32 *str): return the length of an UCS-4 string > > considered as an UTF-8 string > > > > and also the following function will be useful (to allocate > > logical_unicode_str at exact size): > > > > UTF8USC4Length(unsigned char *str): return the length of an utf-8 string > > considered as an USC-4 string > > > > a simple workaround is to replace > > > > visual_str = (char *)safemalloc((str_len + 1) * sizeof(char)); > > > > by > > > > visual_str = (char *)safemalloc((4*str_len + 1) * sizeof(char)); > > > > I do not have the time to write down the fix in the next 5 days (at > > least two others thing todo before: IconMan and LocalePath). > > > > Mikhael, Nadim ? > > Good work at finding the problem. I will try to enable the new code by > allocating more space, today or tomorrow. But I think I already tried to > allocate 3*str_len and it still core dumped... I am sure though your > analyze is correct. Ok, I did some changes. Including removing alloca (not that this helps with speed and core dumps). I allocate 4 * str_len. I don't think it worths to write now more exact calculations when it is the fribidi task to worry about an allocation. Seems to work, although I can't guarantee it will not core dump. Here is some result. It is possible my font is bad, because I don't see spaces between words. But at least I can see the text is more connected. http://fvwm.sf.net/tmp/arabic-nonjoined.gif http://fvwm.sf.net/tmp/arabic-joined.gif Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
