After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 165650 - [API] gst_value_deserialize doesn't work correctly for NULL strings
[API] gst_value_deserialize doesn't work correctly for NULL strings
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.9.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 319388
Reported: 2005-01-29 22:32 UTC by Benjamin Otte (Company)
Modified: 2005-11-19 17:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Benjamin Otte (Company) 2005-01-29 22:32:57 UTC
1. create a GValue of G_TYPE_STRING with value NULL
2. serialize it
3. deserialize the result
4. the result should be NULL

It's not though.
Comment 1 Andy Wingo 2005-07-16 10:10:24 UTC
Interesting. How could you detect NULL though? There is no special string which
could not also be a valid string, unless you prevent valid strings of a certain
name (e.g. 'XXXXXXXXNULL' or something) from being serialized. Or to prevent
NULL from being serialized, which would be more to the point.

Practically speaking, I haven't run into this. Unless you can suggest a way of
fixing this (perhaps a different type), I'd be ok living with a WONTFIX :)
Comment 2 David Schleef 2005-07-16 19:45:57 UTC
I think the problem is more "we allow NULL strings in our api in places where it
might be serialized".
Comment 3 Andy Wingo 2005-11-14 10:53:32 UTC
So... gst_value_serialize should error when given a G_TYPE_STRING with NULL
value, and we should fix places that accept NULL strings that could be
serialized later.
Comment 4 Benjamin Otte (Company) 2005-11-14 11:57:31 UTC
I would personally prefer if the string serialization were able to (de)serialize
NULL strings since NULL strings are valid GValues. This is because at some point
someone might get the idea to serialize GObject properties with this API and
there it is definitely allowed.

FWIW, the D-Bus glib bindings have the same issue. Last I looked they just
errored out on NULL strings which wasn't helpful at all for me.

Next question: Do we serialize to UTF-8 or ASCII? In any case: How should we
handle control characters like line feeds, backspace and so on?

My solution would be to invent some sort of escape character (possibly % to
mimic printf) and use that to escape special cases. % => %%, <someweirdchar> =>
%<unicode-hexvalue-of-weird-char> and NULL => %
Comment 5 Andy Wingo 2005-11-19 16:59:42 UTC
Hi Benjamin,

The escaping idea sounds interesting but there are some issues:

1) creating an escape-based syntax is error-prone -- lots of security holes in
software are in parsers

2) there isn't time to make such a serializer/deserializer in time for the API

So I would prefer to limit the scope of this bug to producing correct results or
producing errors, but not incorrect results. That said the ability to serialize
arbitrary GObject properties is an interesting thought.
Comment 6 Andy Wingo 2005-11-19 17:09:19 UTC
Easy fix in CVS now.