After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613250 - Glib::ustring::format can have problems with char *
Glib::ustring::format can have problems with char *
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: strings
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2010-03-18 15:53 UTC by Debarshi Ray
Modified: 2010-03-26 13:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample code to trigger the bug (681 bytes, text/plain)
2010-03-18 15:55 UTC, Debarshi Ray
  Details
Proposed fix (1.33 KB, patch)
2010-03-19 22:17 UTC, Debarshi Ray
committed Details | Review

Description Debarshi Ray 2010-03-18 15:53:49 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.
Comment 1 Debarshi Ray 2010-03-18 15:55:10 UTC
Created attachment 156468 [details]
Sample code to trigger the bug
Comment 2 Debarshi Ray 2010-03-19 22:10:57 UTC
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.
Comment 3 Debarshi Ray 2010-03-19 22:17:18 UTC
Created attachment 156595 [details] [review]
Proposed fix
Comment 4 Murray Cumming 2010-03-21 12:24:45 UTC
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.
Comment 5 Murray Cumming 2010-03-26 09:42:12 UTC
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.
Comment 6 Daniel Elstner 2010-03-26 13:52:09 UTC
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.