GNOME Bugzilla – Bug 686185
g_date_time_format Transcoding Fails on OSX
Last modified: 2012-11-25 08:10:07 UTC
Because eucjp and UTF-8 aren't the same. I can make a version that does work with eucjp and fence it with HAVE_CARBON, but I'm a bit puzzled about the test: On what system with eucjp support does it work? If the eucjp LC_TIME formats are the same as the UTF-8 ones, how is that testing "non-UTF-8 printf"?
g_date_time_format() always returns UTF-8, regardless of the locale. The test is making sure that we properly convert from eucjp to UTF-8 internally, so as to get the right outputs.
(In reply to comment #1) > g_date_time_format() always returns UTF-8, regardless of the locale. The test > is making sure that we properly convert from eucjp to UTF-8 internally, so as > to get the right outputs. You mean it's supposed to. I've changed the summary to reflect that that's not happening on OSX.
And the problem is that charset.alias looks like this: # This file contains a table of character encoding aliases, # suitable for operating system 'darwin'. # It was automatically generated from config.charset. # Packages using this file: * UTF-8 The end result is that the transcoding never gets called. Rejigging config.charset to use the pre-Tiger hack doesn't fix it, sigh.
From http://git.gnome.org/browse/glib/commit/?id=d5df0a10f142db8216cb41e38ec23d5729956650 : + if (g_strcmp0 (g_get_codeset (), "UTF-8") == 0) This leaks the result of g_get_codeset(). Also, I think you can simply replace this strcmp with g_get_charset(NULL).
(In reply to comment #4) > This leaks the result of g_get_codeset(). Also, I think you can simply replace > this strcmp with g_get_charset(NULL). I like that better. Committed as 4398db5.
Ryan: No, turning off the test for OSX doesn't fix the bug.
Now it's fixed, pushed to master and glib-2-34.