Allow a string in gst_string_unwrap to include unescaped characters that
are not in GST_STRING_IS_ASCII. This extra leniency allows
gst_structure_from_string to, e.g., receive
name, val=(string)"string with space";
Note that many gst tests, and potentially users, exploited this behaviour
by giving
name, val="string with space";
i.e. without the (string) type specifier. This was allowed before
because, without a type specifier, the string was passed to
_priv_gst_value_parse_string with unescape set to TRUE, *rather* than
being sent to gst_string_unwrap. This caused a difference in behaviour
between strings that are or are not preceded by (string). E.g.
name, val=(string)"string with space";
would fail, whilst
name, val="string with space";
would not. And
name, val=(string)"\316\261";
would produce a val="α", whereas
name, val=(string)"\316\261";
would produce a val="316261" (a bug).
The current behaviour is to treat both of these cases the same, which is
desirable. But in order to not break potentially common usage of this
discrepancy (it was in our own tests), the best option is to make string
parsing less strict in general.
New behaviour would be for
name, val=(string)"string with space";
to pass and give val="string with space", and
name, val="\316\261";
would produce a val="α".
Also changed deserializing string test to expect successes where
previously a failure was expected.
In a similar way, this also effected the deserializing of GstStructure,
GstCaps, GstTagList and GstCapsFeatures. So, now
name, val=(structure)"sub-name, sub-val=(string)\"a: \\316\\261\";";
will also pass and give sub-val="a: α". Note that the quote marks
and backslash still need to be escaped for the sub-structure, but other
characters need not be.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/303>
445df0c799