luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-10 11:26:16 +01:00
Code Issues Packages Projects Releases Wiki Activity

Revert "gkeyfile: Temporarily re-allow invalid escapes when parsing strings"

Browse Source 
This reverts commit 4a96727642.

It was a temporary workaround to prevent disruption to apps late on in
the 2.78 cycle. Since we’re now early in the 2.80 cycle, let’s revert
the workaround and allow apps more time to fix their error handling for
`GKeyFile`.

Fixes: #3098
This commit is contained in:
Philip Withnall 2023-10-04 11:01:31 +01:00
parent ab83d965e8
commit 76d77cf623
1 changed files with 1 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
glib/gkeyfile.c
View File

@ -4351,7 +4351,6 @@ g_key_file_parse_value_as_string (GKeyFile *key_file,
break;
case '\0':
g_clear_error (error);
g_set_error_literal (error, G_KEY_FILE_ERROR,
G_KEY_FILE_ERROR_INVALID_VALUE,
_("Key file contains escape character "
@ -4374,25 +4373,11 @@ g_key_file_parse_value_as_string (GKeyFile *key_file,
sequence[1] = *p;
sequence[2] = '\0';
/* FIXME: This should be a fatal error, but there was a
* bug which prevented that being reported for a long
* time, so a lot of applications and in-the-field key
* files use invalid escape sequences without anticipating
* problems. For now (GLib 2.78), message about it; in
* future, the behaviour may become fatal again.
*
* The previous behaviour was to set the #GError but not
* return failure from the function, so the caller could
* explicitly check for invalid escapes, but also ignore
* the error if they want. This is not how #GError is
* meant to be used, but the #GKeyFile code is very old.
*
* See https://gitlab.gnome.org/GNOME/glib/-/issues/3098 */
g_clear_error (error);
g_set_error (error, G_KEY_FILE_ERROR,
G_KEY_FILE_ERROR_INVALID_VALUE,
_("Key file contains invalid escape "
"sequence “%s”"), sequence);
goto error;
}
}
break;