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 <eblake@xxxxxxxxxx>
>> ---
>>
> I think we don't really need this patch at all. It makes sure the
> arguments are only evaluated once, but since this is all conditional
> (not only the safer variants, but the implementation can even be
> provided externally), we still have to care what arguments we pass to
> MIN/MAX.
>
> In other words, I think this actually reduces the safety of our code.
Fair enough, although your complaint could be overcome by rewriting the
patch to do:
#ifdef MIN
# undef MIN
#endif
#define MIN() ...
to ensure our code ALWAYS uses our safe form, rather than what it may
have picked up from somewhere else. On the other hand, ditching the
patch also means I don't have to solve the compilation error about gcc
not liking global variables defined with:
type name[({expr})]
due to it not loking ({}) used in constant expression contexts.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
