1. 19 Jan, 2021 5 commits
    • Chris White's avatar
      structure: add tests of deserializing strings with escapes · 9d2825cc
      Chris White authored and Thibault Saunier's avatar Thibault Saunier committed
      Shows the issue described in
      <gstreamer/gstreamer!303 (comment 272629)>
      Part-of: <gstreamer/gstreamer!303>
    • Henry Wilkes's avatar
      gstvalue: preserve parse behaviour with warning · 5eba2b83
      Henry Wilkes authored and Thibault Saunier's avatar Thibault Saunier committed
      Preserve the previous behaviour where:
          name, val="5";
      passed to gst_structure_from_string would have resulted in an int value,
      rather than a string, despite the quote marks.
      This will be changed to being interpreted as a string in the future, but
      for the time being we will issue a warning about this to give users time
      to fix their code to no longer rely on this bug.
      Part-of: <gstreamer/gstreamer!303>
    • Henry Wilkes's avatar
      gstvalue: make gst_string_unwrap less strict · 445df0c7
      Henry Wilkes authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      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: <gstreamer/gstreamer!303>
    • Henry Wilkes's avatar
      value: add serialize-deserialize tests · 454b121f
      Henry Wilkes authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      Added tests to ensure that the gst_value_deserialize reverses
      Part-of: <gstreamer/gstreamer!303>
    • Henry Wilkes's avatar
      structure: don't unescape values before deserializing · 7f267395
      Henry Wilkes authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      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
      Correspondingly changed a few deserialization functions.
      Fixes gstreamer/gstreamer#452
      Part-of: <gstreamer/gstreamer!303>
  2. 14 Jan, 2021 5 commits
  3. 12 Jan, 2021 1 commit
  4. 11 Jan, 2021 1 commit
  5. 07 Jan, 2021 1 commit
  6. 23 Dec, 2020 1 commit
  7. 22 Dec, 2020 1 commit
  8. 20 Dec, 2020 1 commit
  9. 11 Dec, 2020 3 commits
  10. 10 Dec, 2020 7 commits
  11. 08 Dec, 2020 1 commit
  12. 07 Dec, 2020 5 commits
  13. 04 Dec, 2020 3 commits
    • Thibault Saunier's avatar
      gst: Add new structure/caps/_to_string using the brackets for nesting · c35d4712
      Thibault Saunier authored
      This adds `gst_structure_serialize` and `gst_caps_serialize` which use
      the newly introduced bracket delimiters for nested structures.
      Part-of: <!532>
    • Thibault Saunier's avatar
    • Thibault Saunier's avatar
      structure: Add support for brackets as nested structures/caps specifiers · 322caf88
      Thibault Saunier authored
      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: <gstreamer/gstreamer!532>
  14. 03 Dec, 2020 1 commit
  15. 02 Dec, 2020 3 commits
  16. 20 Nov, 2020 1 commit