Am 15.03.2018 um 18:55 hat John Snow geschrieben: > > > 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 <kw...@redhat.com> wrote: > >>> The following changes since commit > >>> 22ef7ba8e8ce7fef297549b3defcac333742b804: > >>> > >>> Merge remote-tracking branch 'remotes/famz/tags/staging-pull-request' > >>> 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 be6c885842efded81a20f4ca24f0d4e123a80c00: > >>> > >>> block/mirror: change the semantic of 'force' of block-job-cancel > >>> (2018-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 ‘block_job_txn_apply.isra.8’: > >> /home/pm215/qemu/blockjob.c:524:5: error: ‘rc’ may be used > >> uninitialized in this function [-Werror=maybe-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 ? > > > > I think so. > > > > John, I'll just modify your patch 'blockjobs: add prepare callback' to > > initialise rc = 0 in this function and send a v2 pull request. > > > > Kevin > > > > 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.
You only call block_job_txn_apply() in the context of completing a specific job, which has to be in its transaction, so I don't think the list can actually be empty. Not sure how the compiler is able to infer that, though. Kevin