[Bug 702960] gst_element_add_pad()'s pad parameter should be marked as transfer none

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702960
  GStreamer | gstreamer (core) | git

--- Comment #25 from Christoph Reiter (lazka) <reiter.christoph at gmail.com> 2015-01-08 16:29:14 UTC ---
I just noticed that gi already understands transfer-floating as an alias for
transfer-none in this case. So imho moving to transfer-floating should be a
good first step, independent of what the final solution is going to be. It adds
the needed documentation for C users and has the expected transfer type for
current bindings.

Since you were worried (on IRC) about breaking bindings by moving to
transfer-none. I'd assume all scripting bindings sink_ref atm, and vala seems
to ref_sink as well, see this small example:
https://bpaste.net/show/65bdcb07bfff

Affected arguments in gstreamer core I could find:

gst_object_set_parent.object
gst_element_add_pad.pad
gst_device_provider_device_add.device
gst_object_add_control_binding.binding
gst_bin_add.element
gst_registry_add_feature.feature

I'd also like to add that currently none of the above functions really are
transfer-floating, as they don't sink the references in case of an error. Imo,
if you really want proper semantics, this should be fixed as well. This would
also need further changes as some functions depend on this error-case behavior.

* gst_ghost_pad_construct() unrefs a GstPad passed to gst_object_set_parent in
its error path
* gstutils/ghost_up() unrefs a pad after a failed gst_element_add_pad
* gst_element_link_pads_filtered() unrefs a capsfilter after a failed
gst_bin_add
* ...

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.