GNOME Bugzilla – Bug 335713
strange utf8 put in config file
Last modified: 2006-05-30 23:36:25 UTC
If you alter the text of the custom welcome message in gdmsetup, the non-ascii letters of this text are stored in gdm.conf in a quite strange way. The first byte of every UTF-8 sequence is put in the file as a raw byte, but subsequent bytes are escaped as \ooo (the octal value). This way the file becomes invalid UTF-8, does not display correctly with text editors and so on... I guess the welcome message should be stored in normal UTF-8.
Yes, this is annoying. I would accept a patch to store and load Welcome text in the config file in normal UTF-8.
Created attachment 66297 [details] [review] Don't mangle UTF-8 in config file g_strescape mangling utf-8 was already mentioned back in 2001; http://mail.gnome.org/archives/gtk-devel-list/2001-March/msg00492.html and it looks like the situation didn't change. The attached patch defines a new function strescape_but_high which works like g_strescape but only for special chars (\n, \t, etc.), not for high-bit chars (0x7f-0xff). It then uses this function to write key values in config file.
Is any special code needed so that GDM properly reads in the file in the new format, or was the problem only with writing the data?
No special code needed, g_strcompress will read the string without problem.
I notice that the new function strescape_but_high calls malloc to allocate a string, but it doesn't seem to be freed anywhere. Could you fix this and I'll apply the patch. I think this should go into 2.15, do you think it makes sense to go into 2.14? Would it break user's experience if they were using an old configuration file and then upgraded to a version of GDM using this patch? I don't think so, since this only changes the configuration file if it is updated with a new value. But I thought I would ask your opinion as well.
This is modeled on g_strescape which returns (quoting refapi) "a newly-allocated copy of source with certain characters escaped". It is used only once, to replace g_strescape, and the string is then correctly freed (same file, line 604). This is really minor and I don't think it warrants to go into 2.14.
Thanks for talking this through with me. The patch is now in CVS head.