From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TunGy-0001pv-M4 for qemu-devel@nongnu.org; Mon, 14 Jan 2013 11:52:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TunGr-0000ib-V1 for qemu-devel@nongnu.org; Mon, 14 Jan 2013 11:52:32 -0500 Message-ID: <50F437C5.4020905@suse.de> Date: Mon, 14 Jan 2013 17:52:21 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1358121304-21345-1-git-send-email-afaerber@suse.de> <1358121304-21345-2-git-send-email-afaerber@suse.de> <87k3rg2bzf.fsf@blackfin.pond.sub.org> In-Reply-To: <87k3rg2bzf.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 01/10] qom: Make object_resolve_path_component() path argument const List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-trivial , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Anthony Liguori , agraf@suse.de Am 14.01.2013 13:19, schrieb Markus Armbruster: > Andreas F=C3=A4rber writes: >=20 >> This allows to navigate partial well-known paths from an object. >=20 > Why does making the argument const allow such navigation? Without const, object_resolve_path_component(foo, "bar") results in a compile error (09/10 accesses "ide[1]" etc. to avoid exposing the full MacIOState). Apparently this function was so far only used on dynamically generated (non-const) arrays: qom/container.c: child =3D object_resolve_path_component(obj, parts[i]); qom/object.c: child =3D object_resolve_path_component(parent, parts[index]); >> Signed-off-by: Andreas F=C3=A4rber >> Cc: Anthony Liguori >> --- >> include/qom/object.h | 2 +- >> qom/object.c | 2 +- >> 2 Dateien ge=C3=A4ndert, 2 Zeilen hinzugef=C3=BCgt(+), 2 Zeilen entfe= rnt(-) >> >> diff --git a/include/qom/object.h b/include/qom/object.h >> index d43b289..1ef2f0e 100644 >> --- a/include/qom/object.h >> +++ b/include/qom/object.h >> @@ -900,7 +900,7 @@ Object *object_resolve_path_type(const char *path,= const char *typename, >> * >> * Returns: The resolved object or NULL on path lookup failure. >> */ >> -Object *object_resolve_path_component(Object *parent, gchar *part); >> +Object *object_resolve_path_component(Object *parent, const gchar *pa= rt); >> /** >> * object_property_add_child: >> diff --git a/qom/object.c b/qom/object.c >> index 351b88c..03e6f24 100644 >> --- a/qom/object.c >> +++ b/qom/object.c >> @@ -1017,7 +1017,7 @@ gchar *object_get_canonical_path(Object *obj) >> return newpath; >> } >> =20 >> -Object *object_resolve_path_component(Object *parent, gchar *part) >> +Object *object_resolve_path_component(Object *parent, const gchar *pa= rt) >> { >> ObjectProperty *prop =3D object_property_find(parent, part, NULL)= ; >> if (prop =3D=3D NULL) { >=20 > Unrelated: do we really want to go along with glib's basic type typedef > silliness? Elsewhere I have adopted the exact GLib signature since typedefs can be changed at any time. In particular the GCompareFunc using gconstpointer, gint, etc. Not saying I find their GLib usage useful. I admit I didn't review object_property_find(), which uses const char*. So I wouldn't mind sending a v2 if non-g is preferred. Or Anthony or Stefan could just edit the patch in my name before applying. :) Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg