GNOME Bugzilla – Bug 613250
Glib::ustring::format can have problems with char *
Last modified: 2010-03-26 13:52:09 UTC
Glib::ustring::format is throwing a Glib::ConvertError for some Unicode strings (eg., "Užduotys") which are being passed to it as char *. There is no problem if the same strings are passed as const char * or Glib::ustring. The problem arises from the fact that pushing a char * or const char * that points to a Unicode string to a std::wostringstream is resulting in invalid Unicode code points. In this case, the code point corresponding to the letter ž is getting corrupted. These invalid codes are disliked by g_ucs4_to_utf8, which is invoked from Glib::ustring::FormatStream::to_string, and we end up with an exception. (For what it is worth, std::wcout, std::cout are skipping the invalid codepoints instead of blowing up.) This problem manifests itself only for char * and not const char * because Glib::ustring::FormatStream::stream is overloaded for const char * to create a Glib::ustring from the input parameter, which is in turn pushed into the stream. However there is no such overload to handle char * arguments.
Created attachment 156468 [details] Sample code to trigger the bug
I should have mentioned this earlier... When Glib::ustring::format gets char [10] as its template parameter, Glib::ustring::FormatStream::stream(const char *) gets invoked, but when it gets char * as its template parameter, Glib::ustring::FormatStream::stream(const T&) gets invoked.
Created attachment 156595 [details] [review] Proposed fix
Thanks. I'll let Daniel decide this. Daniel, please look at this soon, because we must API freeze again very soon. I guess we should add a test case for it too.
I have committed both the fix and the test. If this is wrong then Daniel still has a small chance to tell us in time.
I'd really love to understand why we need to *overload* (not specialize) for both "const char*" and "char*". Right now this makes no sense to me.