On 04/06/20 23:52, Eric Blake wrote:
> I'm not aware of any immediate bugs in qemu where a second runtime
> evalution 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
On 6/5/20 3:24 AM, David Edmondson wrote:
On Thursday, 2020-06-04 at 16:52:36 -05, Eric Blake wrote:
/* Minimum function that returns zero only iff both values are zero.
Not your change, but "only" is unnecessary here (or iff -> if).
Indeed. Whoever picks this up could make that change (
On 6/5/20 10:24 AM, David Edmondson wrote:
> On Thursday, 2020-06-04 at 16:52:36 -05, Eric Blake wrote:
>
>> /* Minimum function that returns zero only iff both values are zero.
>
> Not your change, but "only" is unnecessary here (or iff -> if).
Maybe we should teach checkpatch.pl to refuse the
On Thursday, 2020-06-04 at 16:52:36 -05, Eric Blake wrote:
> /* Minimum function that returns zero only iff both values are zero.
Not your change, but "only" is unnecessary here (or iff -> if).
dme.
--
But uh oh, I love her because, she moves in her own way.
On 6/4/20 2:52 PM, Eric Blake wrote:
> I'm not aware of any immediate bugs in qemu where a second runtime
> evalution 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
On 6/4/20 4:52 PM, Eric Blake wrote:
I'm not aware of any immediate bugs in qemu where a second runtime
evalution of the arguments to MIN() or MAX() causes a problem, but
evaluation
proactively preventing such abuse is easier than falling prey to an
unintended case down the road. At any rate
I'm not aware of any immediate bugs in qemu where a second runtime
evalution 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 sparked the current pat
