GNOME Bugzilla – Bug 668250
g_date_time_format() produces a non-UTF8 string
Last modified: 2012-01-21 00:51:06 UTC
Function g_date_time_format() is explained in a reference manual as following: ======== In contrast toglib-2.31.10/glib/gi18n.h strftime(), this function always produces a UTF-8 string, regardless of the current locale. Note that the rendering of many formats is locale-dependent and may not match the strftime() output exactly. ======== (http://developer.gnome.org/glib/stable/glib-GDateTime.html#g-date-time-format) But g_date_time_format() produces non-UTF-8 string in some locales actualy. ======== cat > reproduce_bug.c <<EOF #include <stdio.h> #include <locale.h> #include <glib/gdatetime.h> int main( int argc, char** argv ){ char *result; GDateTime *datetime; GTimeVal tv; setlocale( LC_ALL, "" ); tv.tv_sec = tv.tv_usec = 0; datetime = g_date_time_new_from_timeval_local (&tv); result = g_date_time_format (datetime, "%A %a %B %b"); printf ( "date: %s\n", result ); return 0; } EOF gcc reproduce_bug.c $( pkg-config --cflags --libs glib-2.0 ) env LC_TIME=C ./a.out env LC_TIME=ja_JP.eucjp ./a.out ======== Reason, g_date_time_format() calls nl_langinfo() or g_dpgettext() and uses these return values directly. Both functions return locale-depend strings. This bug causes crash of gnome-shell in some locales.
Created attachment 205633 [details] [review] g_date_time_format: fix output in non-UTF-8 locales In non-UTF-8 locales, the translations and nl_langinfo() return values must be converted to UTF-8 before being returned to the caller. Likewise, when making a recursive call to expand a format like '%x', the format string must first be converted to UTF-8. ===== This makes glib/tests/gdatetime much slower, because test_strfime() and test_all_dates() make a huge number of calls to g_date_time_format(), and each one calls g_get_charset() at least once, and apparently that's pretty slow. However, test_printf(), which only calls g_date_time_format() 41 times, isn't really slowed down measurably, so this probably isn't a real-world problem.
Speeding up g_get_charset() is an independent task, I think. This is clearly a necessary correctness fix.
Attachment 205633 [details] pushed as b6a8dec - g_date_time_format: fix output in non-UTF-8 locales