GNOME Bugzilla – Bug 55837
GTK uses locale-specific functions in places where it needs locale-independent ones
Last modified: 2013-03-28 09:40:35 UTC
This is basically a placeholder for a patch that makes GTK use ASCII or UTF-8 routines instead of ones that use the locale-specific character set.
Created attachment 619 [details] [review] patch to use locale-independent calls
One thing is probably wrong in the patch. It uses g_utf8_strcasecmp and probably we want to use a call more like g_utf8_strcoll.
Oops. Please ignore the Makefile.am change that crept in there.
Created attachment 620 [details] [review] patch with a few mistakes corrected
I've applied the gdk/x11/ parts, and the gtk/ parts that aren't specific to Win32. (I haven't touched the gtkfilesel.c parts or the fnmatch.c parts.) I'm assiging this to the win32 component. Once we are happy with the fixes there, it should be moved along to the linux-fb component. Wed Feb 27 11:59:05 2002 Owen Taylor <otaylor@redhat.com> Some ASCII vs. locale fixes from Darin Adler (#55837) * gtk/gtkcombo.c (gtk_combo_find): Implement real case-insensitive comparison using g_utf8_casefold(). * gtk/gtkaccellabel.c (gtk_accel_label_refetch): Fix assignment of gunichar to char by replacing g_unichar_totitle with g_ascii_toupper ... the contents would only be ascii here anyways. * gdk/x11/gdkim-x11.c (_gdk_x11_initialize_locale) * gtk/gtkfontsel.c (gtk_font_selection_show_available_fonts): Replace a calls to g_strcasecmp() with g_ascii_strcasecmp().
I don't see the point in changing strncasecmp to g_ascii_strncasecmp in contexts where one of the strings is a string literal? (Most of the diff is for contexts like that.) (bdfcursor.c is an auxiliary program that was run once and probably never again, as it isn't very likely that the X11 cursor.bdf file going to change. I note now that bdfcursor.c is erroneously included in libgdk_win32_la_SOURCES... It should be a separate noninstalled program, or even just in EXTRA_DIST.)
Why not? Couldn't strncasecmp return true in some cases where the non-ASCII character is a cased version of the ASCII character? I don't think we ever want to call strncasecmp.
Putting win32 bugs on 2.2.0 milestone, since we don't plan on having win32 official for the 2.0.x branch.
Move remaining 2.2.0 bugs to 2.2.1.
Move remaining bugs off 2.2.2 target milestone.
Move remaining bugs off the 2.2.3 milestone
> Couldn't strncasecmp return true in some cases where the > non-ASCII character is a cased version of the ASCII character? Show us an example... Until then closing as NOTABUG.
Seems wrong to close this because *most* of the diff is for changes that aren't necessary. I'd understand if *all* of the diff was. In any case, I'm not following the GNOME project very closely these days, so if you think these changes aren't needed, that's fine with me. An example where strncasecmp would return true, by the way, would be if you compared an uppercase Turkish "I" with the dot with a lowercase "i" in a Turkish locale. The Turkish "I" with dot is a non-ASCII character, and the lowercase "i" is an ASCII character. I'll reopen one more time just so you read this message, then feel free to do whatever you like with the bug.
Patch doesn't apply cleanly; it seems some of the changes have been made already. It could be reviewed quite quickly. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
I really have a hard time believing there would be anything relevant left in the patch.
Closing then.