On 1/4/19 10:49 AM, Jiri Denemark wrote:
> On Fri, Jan 04, 2019 at 10:00:12 -0600, Eric Blake wrote:
>> We might as well take advantage of gcc's extensions for a safer
>> MIN()/MAX() macro.
>>
>> Signed-off-by: Eric Blake
>> ---
>>
> I think we don't really need this patch at all. It makes sure
On Fri, Jan 04, 2019 at 10:00:12 -0600, Eric Blake wrote:
> We might as well take advantage of gcc's extensions for a safer
> MIN()/MAX() macro.
>
> Signed-off-by: Eric Blake
> ---
>
> RFC because we could also try to fall back to older gcc's typeof(a)_a=(a)
> when the newer __auto_type _a=(a)
Hi,
This series was run against 'syntax-check' test by patchew.org, which failed,
please find the details below:
Subject: [libvirt] [RFC PATCH] maint: let MIN/MAX evaluate only once, on modern
compilers
Message-id: 20190104160012.23452-1-ebl...@redhat.com
Type: series
=== TEST SCRIPT BEGIN
On 1/4/19 10:00 AM, Eric Blake wrote:
> We might as well take advantage of gcc's extensions for a safer
> MIN()/MAX() macro.
>
> Signed-off-by: Eric Blake
> ---
>
> RFC because we could also try to fall back to older gcc's typeof(a)_a=(a)
> when the newer __auto_type _a=(a) is not present, and
We might as well take advantage of gcc's extensions for a safer
MIN()/MAX() macro.
Signed-off-by: Eric Blake
---
RFC because we could also try to fall back to older gcc's typeof(a)_a=(a)
when the newer __auto_type _a=(a) is not present, and because I don't
know how to properly probe for
