[Touch-packages] [Bug 1672657] Re: unity::util::unique_gobject() and friends have ambiguous ownership semantics

2017-03-23 Thread Launchpad Bug Tracker 
This bug was fixed in the package unity-api -
8.6+17.04.20170317-0ubuntu1

---
unity-api (8.6+17.04.20170317-0ubuntu1) zesty; urgency=medium

  [ Michael Zanetti ]
  * Add appId property to MirSurfaceInterface

  [ Pete Woods ]
  * unity::util - unique_gobject and share_gobject now throw for
floating references (LP: #1672657)

 -- Lukáš Tinkl   Fri, 17 Mar 2017 11:08:20
+

** Changed in: unity-api (Ubuntu)
   Status: In Progress => Fix Released

-- 
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:
  Fix Released

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 : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1672657] Re: unity::util::unique_gobject() and friends have ambiguous ownership semantics

2017-03-16 Thread Pete Woods 
** Changed in: unity-api (Ubuntu)
   Status: New => In Progress

** Changed in: unity-api (Ubuntu)
   Importance: Undecided => Medium

** Changed in: unity-api (Ubuntu)
 Assignee: (unassigned) => Pete Woods (pete-woods)

-- 
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:
  In Progress

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 : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1672657] Re: unity::util::unique_gobject() and friends have ambiguous ownership semantics

2017-03-16 Thread Launchpad Bug Tracker 
** Branch linked: lp:~pete-woods/unity-api/throw-for-unowned-types-
lp1672657

-- 
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 : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp