Re: [Qemu-block] [Qemu-devel] [PULL 00/41] Block layer patches

[Kevin Wolf]

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 <address@hidden> 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