From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XK8Hb-0004w0-OZ for qemu-devel@nongnu.org; Wed, 20 Aug 2014 11:58:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XK8HV-0002Lt-JI for qemu-devel@nongnu.org; Wed, 20 Aug 2014 11:58:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XK8HV-0002Lf-Bn for qemu-devel@nongnu.org; Wed, 20 Aug 2014 11:58:37 -0400 Message-ID: <53F4C5A6.8000009@redhat.com> Date: Wed, 20 Aug 2014 17:58:30 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Peter Maydell , Peter Crosthwaite Cc: QEMU Developers 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. Paolo