[gst-devel] desired behaviour of "(int) ...." and deserialization functions

[Benjamin Otte]

On Thu, 23 Jun 2005, Thomas Vander Stichele wrote:

> (I'm conveniently ignoring the fact here that int isn't even required to
> be 32 bits wide; it can be less; so on those arch's (int) 0xFF000000
> would not work as a C statement the way you intend it to.)
>
I don't think GStreamer would compile or work on <32 bit systems. I would
even welcome a patch that checks that sizeof (int) >= 4. Aren't FourCCs
saved to an int, too?

> a) is this interpretation of compiler-like casting what we want to
> achieve ?
>
I see two options that are viable:
1) Do exactly what C does.
2) Be even stricter and only allow numbers in the correct range. Possibly
even just numbers in base 10.
For 0.8 b) doesn't work, because we use it for bitmasks, as you said. OTOH
we fire errors for using numbers that are too big, which C doesn't care
about when casting.
For 0.9 I would restrict ints to base 10 and the correct range for ints.
And then I'd fix caps that use bitmasks (that's only RGB video, right?)
Maybe I'd invent GST_TYPE_BITMASK but that sounds a bit like crack to me.

> c) what do people feel should happen when you try to deserialize the
> string "-1" as a G_TYPE_UINT ? Should it fail because it's out of range,
> or should it be deserialized to the value you get when you do (guint)
> -1 ?
>
In an ideal work (ie one where we can break API), throw an error.


Benjamin