Re: gtk bug or glibc locale bug?

Owen Taylor <> 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
"" to /etc/, and the 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:

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]