[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH] qemu-img: initialize MapEntry object
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [PATCH] qemu-img: initialize MapEntry object |
Date: |
Thu, 4 Feb 2016 13:43:33 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 04.02.2016 um 00:38 hat John Snow geschrieben:
> Commit 16b0d555 introduced an issue where we are not initializing
> has_filename for the 'next' MapEntry object, which leads to interesting
> errors in Valgrind and Clang -fsanitize=undefined both.
>
> Zero the stack object at allocation AND make sure the utility to
> populate the fields properly marks has_filename as false if applicable.
>
> Signed-off-by: John Snow <address@hidden>
> ---
> qemu-img.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/qemu-img.c b/qemu-img.c
> index f121980..5a85178 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -2231,6 +2231,9 @@ static int get_block_status(BlockDriverState *bs,
> int64_t sector_num,
> if (file && e->has_offset) {
> e->has_filename = true;
> e->filename = file->filename;
> + } else {
> + e->has_filename = false;
> + e->filename = NULL;
> }
> return 0;
> }
I guess this fixes the bug, but wouldn't it actually be nicer to just
reinitialise the whole object? As everyone knows, I love compound
literals, so I'd make it one big assignment that zeroes everything that
isn't specified:
*e = (MapEntry) {
...
};
> @@ -2264,7 +2267,7 @@ static int img_map(int argc, char **argv)
> BlockDriverState *bs;
> const char *filename, *fmt, *output;
> int64_t length;
> - MapEntry curr = { .length = 0 }, next;
> + MapEntry curr = { .length = 0 }, next = { .length = 0 };
> int ret = 0;
At first I didn't quite understand what this was for, but I think you
tried to cover newly added fields. If you overwrite the whole struct
above, you wouldn't need to initialise it here any more.
Kevin