GstStructure: re-serializing keys/fieldnames in _to_string and _from_string
I've been trying to emulate the behaviour of
gst_structure_from_string as part of a python library within the gst-editing-services project, and I came across a peculiar feature.
I noticed that
GstStructure can (unlike the
name property) have arbitrary keys (field names) set, and some values can cause problems when serializing the structure to be later de-serialized. For example, including
'?' in the key can cause parsing problems, which can cause the de-serializing to fail (it seems that
_priv_gst_value_parse_simple_string is called to fetch the key, which expects
GST_ASCII_IS_STRING characters). The same is true with non-ascii utf8 keys.
But you can also set specific keys that will successfully (without errors or warnings) serialize and de-serialize, but to produce different
GstStructures. For example, you can set a key to be
"key1=(int)0, key2", with a value of
(int)1, which will, under serializing and de-serializing, produce two separate keys named
key2. See the attached demo: demo_gst_structure_key_injection.c
Not sure if this would be considered a problem, since anyone who sets such a key is likely playing around. But maybe the keys should be serialized the same way that string values are (with
gst_value_serialise_string), then on de-serializing a field you simply search for the first un-escaped
'=' (modulo un-escaped spaces) and parse the key to
I just noticed there is a FIXME in
priv_gst_structure_append_to_gstring asking if exactly this should be done. This is an example of an error that would currently go unnoticed.
Under this change, any key that was previously ok (Only
GST_ASCII_IS_STRING characters) would be serialized the same way, i.e. a straight copy of the string (I think the only exception would be a key called
"NULL", which would now be serialized as
"NULL" rather than
NULL). But you could also then support arbitrary keys, including those with non-ascii letters.