[PATCH:libx11] parse_omit_name should increase num of fields before appending encoding

Hong Xu hong at topbug.net
Wed Mar 18 13:39:06 PDT 2015


Alan Coopersmith <alan.coopersmith at oracle.com> writes:

> On 03/15/15 11:39 PM, Hong Xu wrote:
>> parse_omit_name currently does not increase number of fields to 12 after
>> appending encoding, This does not lead to the correct font is a xlfd
>> like "-*-*-medium-r-*-*-33-*" is given.
>>
>> Signed-off-by: Hong Xu <hong at topbug.net>
>>
>> ---
>> Please note that the "if" in this patch is replaced by "while". The
>> reason is that I found the commit 3d69b0a83e62f8f6fbd changed the
>> "while" to "if", which does not seems logically correct for me and
>> actually accidently "fixed" the bug
>> http://sourceware.org/bugzilla/show_bug.cgi?id=10948
>
> Multiple people found and fixed that bug - I am not going to revert
> the change and destroy performance without a better reason than one
> person not understanding the fix.
>
> It's not just the bug you cite, but was also a bug our Solaris i18n team
> found and fixed:
>     https://hg.java.net/hg/solaris-x11~x-s12-clone/rev/6fe48a3a12bf
> and one Thomas Dickey found and fixed while investigating xterm performance:
>     http://invisible-island.net/xterm/xterm.faq.html#slow_menus

From what you said, I think I can conclude 2 problems:

   1. -*-*-medium-r-*-*-33-* cannot be correctly parsed;
   2. performance.

This patch fixes problem 1 (for me); for problem 2, this patch does not
simply revert the change -- it also removed the line

    strcpy(last + 2, font_data->name);

in the loop, which is possibly the performance hoop (because I cannot
reproduce any performance issue, I can only guess).

It would be best if you can test whether the performance issue is fixed
...

Hong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150318/ce2f381c/attachment.sig>


More information about the xorg-devel mailing list