From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [blktap2] fix two 'maybe uninitialized' variables Date: Thu, 12 Jun 2014 11:30:42 +0200 Message-ID: <1402565442.28649.44.camel@Solace> References: <1402488062.16827.90.camel@Solace> <1402564712.8162.5.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2102722647598258700==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Wv1LU-0008IU-7i for xen-devel@lists.xenproject.org; Thu, 12 Jun 2014 09:30:56 +0000 In-Reply-To: <1402564712.8162.5.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, Keir Fraser , Ian Jackson List-Id: xen-devel@lists.xenproject.org --===============2102722647598258700== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BflNBO73B0so+n9Qo0F0" --=-BflNBO73B0so+n9Qo0F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-06-12 at 10:18 +0100, Ian Campbell wrote: > On Wed, 2014-06-11 at 14:01 +0200, Dario Faggioli wrote: > > for which gcc 4.9.0 complains about, like this: > >=20 > > block-qcow.c: In function =E2=80=98get_cluster_offset=E2=80=99: > > block-qcow.c:431:3: error: =E2=80=98tmp_ptr=E2=80=99 may be used uninit= ialized in this function [-Werror=3Dmaybe-uninitialized] > > memcpy(tmp_ptr, l1_ptr, 4096); > > ^ > > block-qcow.c:606:7: error: =E2=80=98tmp_ptr2=E2=80=99 may be used unini= tialized in this function [-Werror=3Dmaybe-uninitialized] > > if (write(s->fd, tmp_ptr2, 4096) !=3D 4096) { >=20 > You initialise both of these to NULL as they are defined, but the > compiler has apparently found a path where these values can be used > without subsequently being initialised, so you are passing NULL to > memcpy/write, which can't be good. >=20 > If you've proved that the compiler is wrong/confused and this cannot > happen please explain the how/why it is wrong here. >=20 Your are right, sorry for this. Being super-unfamiliar with that code, I was sort of relying on the fact that it is correct, especially considering the nature of the warning message. However, I understand, and actually agree, that it really is a bad practice to suppress warnings like this... Let me have a deeper look and see if I can propose a better fix. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-BflNBO73B0so+n9Qo0F0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOZc0IACgkQk4XaBE3IOsR/3gCeJLbvi2OEVZ4TgOQlOaM9G/Kg kd4AnitZvGQMZ8f2zxvegw9wo6D7xNRc =jO1j -----END PGP SIGNATURE----- --=-BflNBO73B0so+n9Qo0F0-- --===============2102722647598258700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2102722647598258700==--