From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYbFO-0007eb-Ey for qemu-devel@nongnu.org; Fri, 11 Apr 2014 09:12:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WYbFK-00042I-4F for qemu-devel@nongnu.org; Fri, 11 Apr 2014 09:11:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WYbFJ-000412-Sh for qemu-devel@nongnu.org; Fri, 11 Apr 2014 09:11:54 -0400 Message-ID: <5347EA15.3040903@redhat.com> Date: Fri, 11 Apr 2014 07:11:49 -0600 From: Eric Blake MIME-Version: 1.0 References: <87bnx3vomf.fsf@blackfin.pond.sub.org> <20140320192134.8983.86526@loki> <53474826.9060903@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SetpsNV2tU6LHXxrlQcioDWNSESsrhtAM" Subject: Re: [Qemu-devel] qapi-commands.py generates code that uses uninitialized variables List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Michael Roth , Anthony Liguori , Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SetpsNV2tU6LHXxrlQcioDWNSESsrhtAM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/11/2014 01:27 AM, Peter Maydell wrote: > On 11 April 2014 02:40, Eric Blake wrote: >> We uncovered a real bug that would be fixed by this patch: >> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01745.html >=20 > No, that's a bug in the called code. The API here defines > that for optional parameters, if the have_foo bool is false > then the foo argument isn't set. The generated code > can't know the correct default value (it just happens > to be 0 in the case you point out, but what if the default > speed were 100?) so this must be handled by the called > code. The called code ALSO needs a fix, but guaranteeing that 'have_foo=3D=3Dfalse' implies 'foo=3D=3D0' is MUCH nicer than 'have_foo=3D= =3Dfalse' implies 'foo is indeterminate'. For this particular caller, an indeterminate foo had detrimental effects, and a known foo=3D=3D0 happene= d to be the right default. I agree that we can't always predict the right default for all callers, but avoiding random behavior can be considered a bug fix in its own right, and if we make it part of the contract that callers can rely on zero initialization, we could simplify a lot of callers that ARE happy with a 0 default. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --SetpsNV2tU6LHXxrlQcioDWNSESsrhtAM 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/ iQEcBAEBCAAGBQJTR+oVAAoJEKeha0olJ0NqS90H/0HVv26oCyfhPVTlUFnWaJoY lVru8Dw0FNBPIxpUECG5192MxgpWJZljCsrHVAHWU+r++POfGDJSackDWAZ2vjl5 DHj1aBy9bJ8REfgDSNPyNXhvcEEVRhQchWp0mt4Yl0Oh15dL/PBYndd47/G4nWer 8+jMl4Ky7fNdRzzeBb0jnZ7n3RXY85KDPfVWz1cAWKffCi7FJlN/pvCxouAoIsaQ 1ZvCEffTGijeBChTg768a6W5HvpCy1EMC1IhyCuYQl9bAsf+N+uLFRFI8fybJs4o Usq6gKU7qJg26K2kDvwt+k1Su+FrvPE8vt2wFPS6X87tpKvh13nVEvWktdqoG90= =osuO -----END PGP SIGNATURE----- --SetpsNV2tU6LHXxrlQcioDWNSESsrhtAM--