Public bug reported:
The unique_gobject() helper has ownership semantics that are likely to
introduce bugs in code using it. It's current logic is essentially:
1. if the object passed as an argument has a floating reference, increment its
ref count.
2. if not, steal the caller's reference.
So we can't tell statically whether this function steals a reference or
creates its own. This makes it more difficult to reason about code
using this helper.
It would be better to choose one of the following:
1. Always create your own reference, using ref_sink() to sink any floating
reference.
2. Always steal the caller's reference. Treat the presence of a floating
reference as an
error, since it indicates that the caller doesn't know if it owns the
object.
(1) can be a pain because the caller will need to do a manual unref if
they pass a newly constructed object to unique_gobject() that doesn't
have a floating reference.
(2) means that the caller will need to do their own ref_sink() call if
they are passing an object they don't actually own a reference to.
We picked (2) for thumbnailer's gobj_ptr smart pointer class.
** Affects: unity-api (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-api in Ubuntu.
https://bugs.launchpad.net/bugs/1672657
Title:
unity::util::unique_gobject() and friends have ambiguous ownership
semantics
Status in unity-api package in Ubuntu:
New
Bug description:
The unique_gobject() helper has ownership semantics that are likely to
introduce bugs in code using it. It's current logic is essentially:
1. if the object passed as an argument has a floating reference, increment
its ref count.
2. if not, steal the caller's reference.
So we can't tell statically whether this function steals a reference
or creates its own. This makes it more difficult to reason about code
using this helper.
It would be better to choose one of the following:
1. Always create your own reference, using ref_sink() to sink any floating
reference.
2. Always steal the caller's reference. Treat the presence of a floating
reference as an
error, since it indicates that the caller doesn't know if it owns the
object.
(1) can be a pain because the caller will need to do a manual unref if
they pass a newly constructed object to unique_gobject() that doesn't
have a floating reference.
(2) means that the caller will need to do their own ref_sink() call if
they are passing an object they don't actually own a reference to.
We picked (2) for thumbnailer's gobj_ptr smart pointer class.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1672657/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
