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 :)

I think the problem is more "we allow NULL strings in our api in places where it
might be serialized".

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.

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 => %

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
freeze.

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.

Easy fix in CVS now.