GstStructure: re-serializing keys/fieldnames in _to_string and _from_string
Hi,
I've been trying to emulate the behaviour of gst_structure_to_string
and 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 GstStructure
s. 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 key1
and 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 gst_value_deserialize_string
.
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.