From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN7dL-0008BU-7f for qemu-devel@nongnu.org; Mon, 10 Mar 2014 17:21:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WN7dG-00034t-8E for qemu-devel@nongnu.org; Mon, 10 Mar 2014 17:21:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WN7dG-00034n-0s for qemu-devel@nongnu.org; Mon, 10 Mar 2014 17:21:10 -0400 Message-ID: <531E2CC0.8080406@redhat.com> Date: Mon, 10 Mar 2014 15:21:04 -0600 From: Eric Blake MIME-Version: 1.0 References: <1394436721-21812-1-git-send-email-cyliu@suse.com> <1394436721-21812-4-git-send-email-cyliu@suse.com> <531E20AB.3090409@redhat.com> In-Reply-To: <531E20AB.3090409@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RKRklurA3KBJdFRtuvgOO5nADOGjX8V7l" Subject: Re: [Qemu-devel] [PATCH v22 03/25] improve some functions in qemu-option.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunyan Liu , qemu-devel@nongnu.org Cc: kwolf@redhat.com, Dong Xu Wang , stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RKRklurA3KBJdFRtuvgOO5nADOGjX8V7l Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/10/2014 02:29 PM, Eric Blake wrote: >> + opt =3D qemu_opt_find(opts, name); >> + if (opt) { >> + g_free((char *)opt->str); >=20 > ...which means the cast is pointless here. >=20 > Hmm. This means that you are giving opt_set() the behavior of 'last > version wins', by silently overwriting earlier versions. If I'm > understanding the existing code correctly, the previous behavior was > that calling opt_set twice in a row on the same name would inject BOTH > names into 'opts', but then subsequent lookups on opts would find the > FIRST hit. Doesn't that mean this is a semantic change: >=20 > qemu -opt key=3Dvalue1,key=3Dvalue2 >=20 > would previously set key to value1, but now sets key to value2. I've played with this a bit more, and now am more confused. QemuOpts is a LOT to comprehend. Pre-patch, 'qemu-system-x86_64 -nodefaults -machine type=3Dnone,type-noone' displayed a help message about unknown machine type "noone", while swapping type=3Dnoone,type=3Dnone proceeded with the 'none' type. So the last version silently won, which was not the behavior I had predicted. Post-patch, I get a compilation error (so how did you test your patch?): qapi/opts-visitor.c: In function =E2=80=98opts_start_struct=E2=80=99: qapi/opts-visitor.c:146:31: error: assignment discards =E2=80=98const=E2=80= =99 qualifier from pointer target type [-Werror] ov->fake_id_opt->name =3D "id"; ^ If I press on in spite of that warning, then I get the same behavior where the last type=3D still wins on behavior. So I'm not sure how it al= l worked, but at least behavior wise, my one test didn't uncover a regressi= on. Still, I'd feel a LOT better with a testsuite of what QemuOpts is supposed to be able to do. tests/test-opts-visitor.c was the only file in tests/ that even mentions QemuOpts. >> @@ -744,16 +777,24 @@ void qemu_opt_set_err(QemuOpts *opts, const char= *name, const char *value, >> int qemu_opt_set_bool(QemuOpts *opts, const char *name, bool val) >=20 >> + opt =3D qemu_opt_find(opts, name); >> + if (opt) { >> + g_free((char *)opt->str); >=20 > Another pointless cast. Maybe not pointless, if you end up not removing the const in the struct declaration due to the compile error; but that brings me back to my earlier question - since the compiler error proves that we have places that are assigning compile-time string constants into the name field, we must NOT call g_free on those copies - how does your code distinguish between a QemuOpt that is built up by mallocs, vs. one that is described by compile-time constants? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RKRklurA3KBJdFRtuvgOO5nADOGjX8V7l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTHizAAAoJEKeha0olJ0Nq2IwIAKfqW5azVGqJNpqQ/cA1YtkW q969JVjsezBn1AfvfzShCxSzlVSON1nDmyE0hvuCXfMXDLfitruv+cvg23oZjeXS inkM80NXouZYRU07ic+keaOI3J+ixts3K0WGLjJJ44mc/IfPqvfMVahSOQn8KeJE pkcudBow/Y/GiBmV3NnB6j98+9Hb5LejRVm/XZhz1AeiU9Hjoc4+UJSxB7kPjuZF okN5ZWWTvwwzT3qst+55/Bhhi8bfUcVDpeq3YBnHqUB2ojZW+YCupEDYQJM+vUqP kPDVO9Wn2cPJ7QyesYvDiKAmoXQnJUat+yUabm2QS9zP4jSxYPTrYPbReNW+RGs= =1Ne3 -----END PGP SIGNATURE----- --RKRklurA3KBJdFRtuvgOO5nADOGjX8V7l--