Re: wcwidth replacement problems

[Alexander V. Lukyanov]

On Sun, Aug 24, 2008 at 12:29:06PM +0200, Bruno Haible wrote:
> > +    dnl On Solaris 8, wcwidth(0x2022) (BULLET) returns -1.
> 
> This is not the case for me:

I'm sorry. In my case it also gives 2, not -1. (I forgot to call setlocale
in the new test program, oops). New patch attached.

> Which looks all fine. (Giving the BULLET a width of 2 is a bit strange, but
> not really wrong.)

Well, it does not seem to match current xterm behavior, and thus leads to
strange visual results. I don't know, maybe it is an xterm problem, but the
easiest way was to substitute wcwidth.

Earlier I used my own autoconf tests and mk_wcwidth replacement, but recently
have decided to move to gnulib (with gnulib-tool).

> > The slowness is probably caused by checking the charset string every time
> > wcwidth is called. I'm not sure which way to fix it would be correct, 
> > probably
> > caching the check result will help.
> 
> When would the cache be invalidated? You cannot hook into setlocale().

Unfortunately.

> > BTW, why not use this one: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c ?
> > It's public domain.
> 
> It has also its bugs [1]. Additionally, it's slower because it uses binary
> search rather than immediate table accesses.

Let's measure it.

$ time ./wcwidth-solaris 
wcwidth(0x2022)=2

real    0m2.205s
user    0m2.200s
sys     0m0.000s

$ time ./wcwidth-rpl 
wcwidth(0x2022)=1

real    0m55.477s
user    0m55.350s
sys     0m0.000s

$ time ./wcwidth-mk 
wcwidth(0x2022)=1

real    0m1.944s
user    0m1.940s
sys     0m0.010s

So despite the binary search the mk version it the fastest. The test program:
#include <locale.h>
#include <stdio.h>
int main()
{
   int i,j;
   setlocale(LC_ALL,"en_US.UTF-8");
   printf("wcwidth(0x2022)=%d\n",wcwidth(0x2022));
   for(j=0; j<300; j++)
      for(i=0; i<0x10000; i++)
         wcwidth(i);
   return 0;
}

-- 
   Alexander.

diff
Description: Text document