Re: gtk bug or glibc locale bug?

[Changwoo Ryu <cwryu adam kaist ac kr>]

Owen Taylor <otaylor@redhat.com> writes:

> The problem the code is supposed to detect, is that under 
> stock glibc (I don't know about the Debian-modified glibc)
> the mb* functions always deal in UTF-8, which isn't useful
> for what GTK+ wants to do. 
>
> "0xc0\n" is not a valid UTF8 string, hence the return of -1.
> This tells GTK+ - OK, the C library's multibyte functions
> aren't useful, so treat everything as 1 byte.

Yes, I can understand.  (*sigh*)

The wcsmbs package is a workaround for multibyte users.  It put
"libwcsmbs.so" to /etc/ld.so.preload, and the libwcsmbs.so redefines
mb* and wc* functions.  mb* function is not only for UTF-8 encoding in
this environment.

> I think the correct thing to do, in the short term, is
> to apply something like:
> 
>  ftp://ftp.gtk.org/pub/gtk/patches/gtk-a-higuti-980912-0.patch.gz

I just read the patch.  But the patch breaks binary compatibility.
(We need to use GTK+ *now*.)

How about (MB_CUR_MAX >= 3) after the "\xc0" check?  It seems OK to
me.  Is there any 1-byte locale whose MB_CUR_MAX >= 3, or multibyte
locale whose MB_CUR_MAX < 3 ?

----------------------------------------------------------------------
       setlocale (LC_CTYPE, "C");
       gtk_use_mb = (mblen ("\xc0", MB_CUR_MAX) == 1);
       setlocale (LC_CTYPE, current_locale);
+      if (! gtk_use_mb && (MB_CUR_MAX >= 3))
+        gtk_use_mb = TRUE;
     }
 
   g_free (current_locale);
----------------------------------------------------------------------

Please comment about this.

> which switches over the Entry and Text widget to using wide
> characters. Locale-dependent variable-width encodings are just not
> reliable. In the long term, Unicode is the right way to go.

I agree.  I hope I could contribute to this area.