Re: [Xen-devel] [PATCH] Initialize ioreq_t in hvmemul_do_io()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.05.14 at 14:48, <paul.durrant@xxxxxxxxxx> wrote:
> All relevant fields of the ioreq_t are properly initialized but coverity
> complains about vp_eport being uninitialized (ID 1215178) because it is
> the subject of a struct copy in hvm_send_assist_req().
> 
> Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> Cc: Keir Fraser <keir@xxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
>  xen/arch/x86/hvm/emulate.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 904c71a..e516194 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -57,7 +57,7 @@ static int hvmemul_do_io(
>      int value_is_ptr = (p_data == NULL);
>      struct vcpu *curr = current;
>      struct hvm_vcpu_io *vio;
> -    ioreq_t p;
> +    ioreq_t p = { 0 };

To be honest, I dislike fixes like this to address tool shortcomings. It's
not like this is giaramteed to be just a single instruction that gets
added (maybe the compiler can figure this, but I would want to rely
on it.

If it's known to just be one member, can't that (with a suitable but
brief comment) be added to the set of field initializations further
down in the function? That would still be code there just to please
Coverity, but it would be guaranteed to be a single instruction.

Btw., Andrew, can one identify at build time that a build is done
just for Coverity's inspection? If so, rather than a comment a
suitable preprocessor conditional might be enough documentation
in cases like this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel