From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewX6i-0001t5-F7 for qemu-devel@nongnu.org; Thu, 15 Mar 2018 13:56:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewX6h-0000oV-M0 for qemu-devel@nongnu.org; Thu, 15 Mar 2018 13:56:04 -0400 References: <20180313161803.1814-1-kwolf@redhat.com> <20180315165649.GE3876@localhost.localdomain> From: John Snow Message-ID: Date: Thu, 15 Mar 2018 13:55:48 -0400 MIME-Version: 1.0 In-Reply-To: <20180315165649.GE3876@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 00/41] Block layer patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Peter Maydell Cc: QEMU Developers , Qemu-block On 03/15/2018 12:56 PM, Kevin Wolf wrote: > Am 15.03.2018 um 17:42 hat Peter Maydell geschrieben: >> On 13 March 2018 at 16:17, Kevin Wolf wrote: >>> The following changes since commit 22ef7ba8e8ce7fef297549b3defcac3337= 42b804: >>> >>> Merge remote-tracking branch 'remotes/famz/tags/staging-pull-reques= t' into staging (2018-03-13 11:42:45 +0000) >>> >>> are available in the git repository at: >>> >>> git://repo.or.cz/qemu/kevin.git tags/for-upstream >>> >>> for you to fetch changes up to be6c885842efded81a20f4ca24f0d4e123a80c= 00: >>> >>> block/mirror: change the semantic of 'force' of block-job-cancel (2= 018-03-13 16:54:47 +0100) >>> >>> ---------------------------------------------------------------- >>> Block layer patches >>> >>> ---------------------------------------------------------------- >> >> I get a compile failure here on some hosts: >> >> /home/pm215/qemu/blockjob.c: In function =E2=80=98block_job_txn_apply.= isra.8=E2=80=99: >> /home/pm215/qemu/blockjob.c:524:5: error: =E2=80=98rc=E2=80=99 may be = used >> uninitialized in this function [-Werror=3Dmaybe-uninitialized] >> return rc; >> ^ >> >> I guess the compiler can't always figure out whether there is >> guaranteed to be at least one thing in the list ? >=20 > I think so. >=20 > John, I'll just modify your patch 'blockjobs: add prepare callback' to > initialise rc =3D 0 in this function and send a v2 pull request. >=20 > Kevin >=20 Oh, interesting. I guess technically the list COULD be empty and that'd be perfectly valid. I wonder why my compiler doesn't complain? Anyway, initializing to zero seems like the correct behavior, thanks. --js