[9913] in The GTK GIMP ToolKit mailing list archive

home help back first fref pref prev next nref lref last post

[gtk-list] Re: gtk bug or glibc locale bug?

daemon@ATHENA.MIT.EDU (Changwoo Ryu)
Fri Nov 6 00:16:42 1998

To: gtk-list@redhat.com
From: Changwoo Ryu <cwryu@adam.kaist.ac.kr>
Date: 06 Nov 1998 14:15:50 +0900
In-Reply-To: Owen Taylor's message of "05 Nov 1998 23:21:11 -0500"
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com

Owen Taylor <otaylor@redhat.com> writes:

> > 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.
> 
> Hmmm, this is somewhat ugly, since a conformant C library
> could report MB_CUR_MAX as 1024 always and not handle
> multibyte characters at all, thought it would work
> on all machines I know of currently.

Mm..  But the \xc0 check is also ugly, isn't it?

If "C" locale is same as US-ASCII, mblen() result can be -1.  And C
library can pass the \xc0 check and not handle mb* functions at all.

Why does the current code set gtk_use_mb value by "C" locale, not by
current locale?  I think it is a bug to be fixed.

-- 
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null


home help back first fref pref prev next nref lref last post