From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKIlf-0000qL-Hy for qemu-devel@nongnu.org; Wed, 20 Aug 2014 23:10:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKIlZ-0007sH-CG for qemu-devel@nongnu.org; Wed, 20 Aug 2014 23:10:27 -0400 Received: from mail-vc0-f177.google.com ([209.85.220.177]:50311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKIlZ-0007sB-7H for qemu-devel@nongnu.org; Wed, 20 Aug 2014 23:10:21 -0400 Received: by mail-vc0-f177.google.com with SMTP id hy4so9906845vcb.8 for ; Wed, 20 Aug 2014 20:10:20 -0700 (PDT) MIME-Version: 1.0 Sender: peter.crosthwaite@petalogix.com In-Reply-To: <53F4C5A6.8000009@redhat.com> References: <53F4C5A6.8000009@redhat.com> Date: Thu, 21 Aug 2014 13:10:20 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH bugfix v1 3/3] qom: object.h: Update object_get_canon_path* doc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , QEMU Developers On Thu, Aug 21, 2014 at 1:58 AM, Paolo Bonzini wrote: > Il 20/08/2014 11:07, Peter Maydell ha scritto: >> The other thing you need to say is that the returned string is >> only valid for as long as the object remains a child property >> of its parent. (Is that right? I'm not clear. It also sounds like >> a really awkward lifetime management requirement, which >> suggests to me that really the "return-a-copy" semantics are >> nicer.) > > They are indeed nicer, but harder to use in C. > > Unparenting is (currently) always done under the BQL, so guaranteeing > that the returned string stays alive as long as you use it is currently > not a problem. This might change in the future, but I don't see many > reasons to get rid completely of the BQL (as opposed to the surgical > moving of stuff outside it that we've been doing so far). > >> Having object_get_canonical_path_component() and >> object_get_canonical_path() having different return value >> ownership semantics is likely to be a bit confusing I think. > > Right, though that could be solved by renaming the _component() function. > Yes that had crossed my mind too. object_get_canonical_path_component is a mouthful and it's usages suggest object_get_name or object_get_instance_name would be more fitting. The fact that it is a canonical_path_component is more of an implementation detail rather than its externally useful functionality. Regards, Peter > Paolo >