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 674345 - cssprovider: Make sure to print out file name in css warnings
cssprovider: Make sure to print out file name in css warnings
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-04-18 17:38 UTC by Stef Walter
Modified: 2012-04-20 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
cssprovider: Make sure to print out file name in css warnings (1.33 KB, patch)
2012-04-18 17:38 UTC, Stef Walter
none Details | Review

Description Stef Walter 2012-04-18 17:38:03 UTC
Warnings without a file name aren't super helpful:

Gtk-WARNING **: Theme parsing error: (null):848:18: Not using units is deprecated. Assuming 'px'.
Comment 1 Stef Walter 2012-04-18 17:38:05 UTC
Created attachment 212308 [details] [review]
cssprovider: Make sure to print out file name in css warnings

 * Use the file basename if display name returns %NULL
Comment 2 Benjamin Otte (Company) 2012-04-19 13:25:57 UTC
From the gio docs:

The base name is a byte string (*not* UTF-8). It has no defined encoding or rules other than it may not contain zero bytes. If you want to use filenames in a user interface you should use the display name that you can get by requesting the G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME attribute with g_file_query_info(). 

So I suppose that patch is wrong.

In fact, this looks like a bug in GResourceFile not providing the display name.
Comment 3 Stef Walter 2012-04-19 15:59:12 UTC
This isn't used in the interface. It's used in a g_warning. IMO it's unnecessary to use the display name here at all.
Comment 4 Benjamin Otte (Company) 2012-04-19 16:06:21 UTC
g_warning() requires UTF-8, no?
Comment 5 Stef Walter 2012-04-19 16:10:30 UTC
No. It correctly escapes invalid characters.

	g_warning ("\xF3\xF3\n");

Will print.

	WARNING **: \xf3\xf3
Comment 6 Benjamin Otte (Company) 2012-04-19 18:05:28 UTC
That's cool. I didn't know that. But are you sure this is not just glibc being awesome? Because looking at the code, it uses the standard printf machinery of the OS, and its specification (man 3 printf) says:

The format string is a character string, beginning and ending in its initial shift state, if any. The format string is composed of zero or more directives: ordinary characters (not %), which are copied unchanged to the output stream [...]

For %s that same page says:

The const char * argument is expected to be a pointer to an array of character type (pointer to a string). Characters from the array are written up to (but not including) a terminating null byte.

So strictly speaking, that printf() implementation that your system is using is wrong.
Comment 7 Stef Walter 2012-04-19 18:17:34 UTC
Looks like g_log_default_handler uses the internal escape_string function to handle non-utf8 strings. Nice feature.

glibc doesn't help out:

   printf ("\xF3\xF3\n");

produces garbage:

   �
Comment 8 Benjamin Otte (Company) 2012-04-20 12:42:10 UTC
Fixed in master and glib-2-32 branch.