GNOME Bugzilla – Bug 604861
Glib->warning etc not wide chars in __WARN__ handler
Last modified: 2021-07-05 12:22:23 UTC
Created attachment 149943 [details] failing program A Glib->warning message and related stuff reaches a $SIG{__WARN__} handler with a byte string, where I hoped it would be a wide-char string, ie. utf8_on. For example the program foo.pl attached prints "not utf8". I struck this in LANG=de where translations of some of gtk's stupid warning messages trying to make you buy the "hicolor" theme have utf8 chars. I suppose gperl_log_handler doesn't propagate utf8-ness when it calls the plain C warn() func. Is there a utf8 version of that? Is it possible to build a utf8 string and call CORE::warn() or wherever the perl-level one lives? Or is it as easy as turning on the utf8 flag on PL_mess_sv (perhaps temporarily) if you want that on your warning?
Created attachment 236444 [details] [review] Ensure that Glib::Log messages are marked as UTF-8-encoded
Messing with PL_mess_sv seems dangerous, so how about this patch?
Are you sure about sv_2mortal() in this context? How far away is a FREETMPS (or whatever it is that normally cleans up)? Perhaps an explicit SvREFCNT_dec() when finished. A SIG{__WARN__} handler could still take its own reference to the sv if it wanted, I imagine. Might be worth exercising such a ref in the tests either way.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME?utf8=%E2%9C%93&filter=perl- Thank you for your understanding and your help.