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>
No longer call _priv_gst_value_parse_string with unescape set to TRUE
before passing a value to gst_value_deserialize in
_priv_gst_value_parse_value. This latter function is called by
gst_structure_from_string and gst_caps_from_string.
When gst_structure_to_string and gst_caps_to_string are called, no
escaping is performed after calling gst_value_serialize. Therefore, by
unescaping the value string, we were introducing an additional operation
that was not performed by the original *_to_string functions. In
particular, this has meant that the derialization functions for many
non-basic types are incomplete reverses of the corresponding
serialization function (i.e., if you pipe the output of the
serialization function into the deserialization function it could fail)
because they have to compensate for this additional escaping operation,
when really this should be the domain of the deserialization functions
instead.
Correspondingly changed a few deserialization functions.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/303>
This introduces a more human friendly syntax to specify nested
structures It does so by using 2 different markers for opening and
closing them instead of abusing quotes which lead to requiring an insane
amount of escaping to match nesting levels.
The brackets (`[` and `]`) have been chosen as they avoid complex
constructions with curly brackets (or lower/higher than signs) where you
could have structures embedded inside arrays (which also use curly
brackets), ie. `s, array=(structure){{struct}}` should be parsed as an
array of structures, but the cast seems to imply something different. We
do not have this issue with brackets as they are currently used for
ranges, which can only be casted to numeric types.
This commit does not make use of that new syntax for serialization as
that would break backward compatibility, so it is basically a 'sugar'
syntax for humans. A notice has been explicitly made in the
documentation to let the user know about it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/532>
Typing hints can only be passed to gst_value_deserialize()
through the type of the passed-in value. This means deserialization
can only target the desired type for the top-level elements,
making it for example impossible to deserialize an array of
flags to the expected type.
This commit exposes a new function, gst_value_deserialize_full(),
that takes an optional pspec as the extra parameter, and updates
the deserialization code to pass around that pspec, or the
element_spec when recursively parsing the elements of a list-type
value.
This allows for example passing arrays of flags through the
command line or gst_util_set_object_arg, eg:
foo="<bar,bar+baz>"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/629>
Before that commit `{test, }` wouldn't be accepted as an array
because of the trailing coma, the commit fixes that.
At the same time, the code has been refactored to avoid special casing
the first element of the list, making `{,}` or `<,>` valid lists.
We won't be able to do ASSERT_CRITICAL, but the main body of the tests
are still valid, and given we ship GStreamer with this configuration, it
is important to be able to run some tests against it.
Allows proper usage of structures in structures in caps. Subtraction
is not implemented due to complications with empty fields representing
all possible values.
The only implementation that doesn't delegate to the already existing
GstStructure functions is the union function.
https://bugzilla.gnome.org/show_bug.cgi?id=775796
GstFlagSet is a new type designed for negotiating sets
of boolean capabilities flags, consisting of a 32-bit
flags bitfield and 32-bit mask field. The mask field
indicates which of the flags bits an element needs to have
as specific values, and which it doesn't care about.
This allows efficient negotiation of arrays of boolean
capabilities.
The standard serialisation format is FLAGS:MASK, with
flags and mask fields expressed in hexadecimal, however
GstFlagSet has a gst_register_flagset() function, which
associates a new GstFlagSet derived type with an existing
GFlags gtype. When serializing a GstFlagSet with an
associated set of GFlags, it also serializes a human-readable
form of the flags for easier debugging.
It is possible to parse a GFlags style serialisation of a
flagset, without the hex portion on the front. ie,
+flag1/flag2/flag3+flag4, to indicate that
flag1 & flag4 must be set, and flag2/flag3 must be unset,
and any other flags are don't-care.
https://bugzilla.gnome.org/show_bug.cgi?id=746373
Don't unwrap strings that start but don't finish with a double quote. If a
string is delimited by two quotes we unescape them and any special characters
in the middle (like \" or \\). If the first character or the last character
aren't a quote we assume it's part of an unescaped string.
Moved some deserialize_string unit tests because we don't try to unwrap strings
missing that second quote anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=688625
Otherwise negative values will sets all of the 64 bits due to two's
complement's definition of negative values.
Also add a test for negative int ranges.
Checking twice the lower bound is great (you never know, it might change
between the two calls by someone using emacs butterfly-mode), but it's a bit
more useful to check the higher bound are also identical.
Detected by Coverity
Wrap caps strings so that it can handle serialization and deserialization
of caps inside caps. Otherwise the values from the internal caps are parsed
as if they were from the upper one
https://bugzilla.gnome.org/show_bug.cgi?id=708772
Set operations on the bitmasks don't make much sense and result
in invalid caps when used as a channel-mask. They are now handled
exactly like integers.
This functionality was not used anywhere except for tests.
https://bugzilla.gnome.org/show_bug.cgi?id=691370
This re-uses existing code and makes sure we properly serialise
and deserialise datetimes where not all fields are set (thus
fixing some warnings when serialising such datetimes).
Which we had to add because GLib didn't have it
back in the day. Port everything to plain old
G_TYPE_DATE, which is also a boxed type. Ideally
we'd just use GDateTime for everything, but it
doesn't support not setting some of the fields
unfortuntely (which would be very useful for
tag handling in general, if we could express
2012-01 for example).
https://bugzilla.gnome.org/show_bug.cgi?id=666351
