1. 02 Feb, 2021 4 commits
  2. 31 Jan, 2021 1 commit
  3. 28 Jan, 2021 1 commit
    • Aleksandr Slobodeniuk's avatar
      gstvalue: fix compilation warning in "holds" macros · ec834321
      Aleksandr Slobodeniuk authored and GStreamer Marge Bot's avatar GStreamer Marge Bot committed
      GST_VALUE_HOLDS_... macros may cause -Waddress warning
      on gcc if GValue is allocated on stack:
      gstvalue.h:145:46: warning: the comparison will always
      evaluate as ‘true’ for the address of ‘v’ will never
      be NULL [-Waddress]
       #define GST_VALUE_HOLDS_CAPS(x)         ((x) != NULL &&
        G_VALUE_TYPE(x) == _gst_caps_type)
      Fixes #653
      Part-of: <!738>
  4. 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>
  5. 14 Jan, 2021 5 commits
  6. 12 Jan, 2021 1 commit
  7. 11 Jan, 2021 1 commit
  8. 07 Jan, 2021 1 commit
  9. 23 Dec, 2020 1 commit
  10. 22 Dec, 2020 1 commit
  11. 20 Dec, 2020 1 commit
  12. 11 Dec, 2020 3 commits
  13. 10 Dec, 2020 7 commits
  14. 08 Dec, 2020 1 commit
  15. 07 Dec, 2020 5 commits
  16. 04 Dec, 2020 2 commits