qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 10/25] util: Add qemu_guest_getrandom and associa


From: Richard Henderson
Subject: Re: [Qemu-devel] [PULL 10/25] util: Add qemu_guest_getrandom and associated routines
Date: Thu, 30 May 2019 08:41:15 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 5/30/19 6:29 AM, Peter Maydell wrote:
> On Wed, 22 May 2019 at 19:42, Richard Henderson
> <address@hidden> wrote:
>>
>> This routine is intended to produce high-quality random numbers to the
>> guest.  Normally, such numbers are crypto quality from the host, but a
>> command-line option can force the use of a fully deterministic sequence
>> for use while debugging.
> 
>> +void qemu_guest_getrandom_nofail(void *buf, size_t len)
>> +{
>> +    qemu_guest_getrandom(buf, len, &error_fatal);
>> +}
>>
> 
> Hi; Coverity complains about this because in the other 4 places
> where we call qemu_guest_getrandom() we check its return
> value, but here we ignore it. If qemu_guest_getrandom() can't
> fail ever then we don't need the separate _nofail() version.
> If it can fail sometimes but not here then we should assert()
> so with a comment explaining why it can't fail, or we should
> do an error-exit check like qdev_init_nofail().
> (This is CID 1401701.)

Because of &error_fatal, we will have already exited on error.  As a qapi
programming pattern, that seems clear in this context.

I don't see how the qdev_init_nofail pattern is an improvement (although in
that specific case we certainly produce a better error message).  If we insist
on that pattern, then we should remove error_fatal and error_abort entirely.

Would coverity be happy with casting the return value to void?


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]