GNOME Bugzilla – Bug 781438
value: NULL string serialization/deserialization
Last modified: 2017-04-20 17:44:37 UTC
Following commits: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=0b9eb621b69b06df350ba25cb3a07ad9d23aef88 http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=7699b8a1bc49f30cd9a0c300831a085516f5442e http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=dd1f0f49abfb35e38e7a2fa3a9229a384fbd0c9b I think we disallow NULL strings for a reason, and in taglists they are explicitly forbidden. What is your use-case for these changes, why do you need NULL strings? Can't you use "" or just not set the string at all? Arguably NULL is not a valid string at all. IMHO we should revert these for 1.12 and reconsider that afterwards. It's not a change that should be added right before the release as we will have to support this behaviour forever. Same goes for GstStructure (3rd commit).
We use it to serialize events in the intersink/intersrc combo (rewritten version soon at bug #752214). And there are real NULL strings in events and queries. For example, gst_query_new_uri() creates a query with a NULL string. So having NULL strings in structures is already in our API.
Also, thaythan did 7bf3554228f52e06e in 2009 explicitly to allow them.
While we're at it, GstMessage of the error type often have a NULL debug string.
Ok, that would've been useful in the commit message but if we have such situations already anyway this seems fine. Note that there are still enough other cases where deserialization will fail because of "NULL" (various objects without serializer). Any serialization/deserialization approach via our current support for that is not going to scale and you'll need a custom mechanism for exactly the things you are going to support sooner or later.