Peter Maydell writes:
> On Fri, 26 Jun 2020 at 14:57, Paolo Bonzini wrote:
>>
>> From: Eric Blake
>>
>> I'm not aware of any immediate bugs in qemu where a second runtime
>> evaluation of the arguments to MIN() or MAX() causes a problem, but
>> proactively preventing such abuse is easier than f
On 29/06/20 17:23, Eric Blake wrote:
>>
>>
>> Can we do something (eg providing fallback less-intelligent
>> versions of the macro ifdef __COVERITY__) to help it?
>
> Absolutely; I see we've done similar in include/qemu/thread.h. I'll
> post something later today.
Done already, you're in Cc. :)
On 6/27/20 4:35 PM, Peter Maydell wrote:
On Fri, 26 Jun 2020 at 14:57, Paolo Bonzini wrote:
From: Eric Blake
I'm not aware of any immediate bugs in qemu where a second runtime
evaluation of the arguments to MIN() or MAX() causes a problem, but
proactively preventing such abuse is easier than
On Fri, 26 Jun 2020 at 14:57, Paolo Bonzini wrote:
>
> From: Eric Blake
>
> I'm not aware of any immediate bugs in qemu where a second runtime
> evaluation of the arguments to MIN() or MAX() causes a problem, but
> proactively preventing such abuse is easier than falling prey to an
> unintended c
From: Eric Blake
I'm not aware of any immediate bugs in qemu where a second runtime
evaluation of the arguments to MIN() or MAX() causes a problem, but
proactively preventing such abuse is easier than falling prey to an
unintended case down the road. At any rate, here's the conversation
that spa
