On 10/09/2017 03:07 PM, Jeff Cody wrote: > On Tue, Oct 03, 2017 at 09:00:34PM -0500, Eric Blake wrote: >> We are gradually converting to byte-based interfaces, as they are >> easier to reason about than sector-based. Convert another internal >> type (no semantic change), and rename it to match the corresponding >> public function rename. >> >> Signed-off-by: Eric Blake <ebl...@redhat.com> >> Reviewed-by: Fam Zheng <f...@redhat.com> >> Reviewed-by: John Snow <js...@redhat.com> >> >> ---
>> static void coroutine_fn bdrv_get_block_status_above_co_entry(void *opaque)
>> {
>> - BdrvCoGetBlockStatusData *data = opaque;
>> + BdrvCoBlockStatusData *data = opaque;
>> + int n;
>>
>> data->ret = bdrv_co_get_block_status_above(data->bs, data->base,
>> data->mapping,
>> - data->sector_num,
>> - data->nb_sectors,
>> - data->pnum,
>> + data->offset >>
>> BDRV_SECTOR_BITS,
>> + data->bytes >>
>> BDRV_SECTOR_BITS,
>> + &n,
>> data->file);
>> + *data->pnum = n * BDRV_SECTOR_SIZE;
>
> This throws a warning:
>
> block/io.c: In function ‘bdrv_get_block_status_above_co_entry’:
> block/io.c:1995:21: error: ‘n’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized] *data->pnum = n * BDRV_SECTOR_SIZE;
>
Ugh - my curse of compiling development builds with -g instead of -O2,
so I didn't see the warning. Ideally, it would be nice if all the
various bdrv_*_block_status functions would set *pnum to a sane value on
all exit paths, including errors, but that is not the case in
bdrv_co_get_block_status_above().
>
> It is fixed a couple patches from now, but it will still break git-bisect.
Indeed. Will fix on respin, as I have to do a v6 anyways for some minor
rebasing conflict resolution.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
