[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in

From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers
Date: Wed, 13 Jul 2016 09:50:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 12 July 2016 at 19:23, Eric Blake <address@hidden> wrote:
>> This violates POSIX, which requires that:
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html#tag_13_48
>> "Each instance of these macros shall be replaced by a constant
>> expression suitable for use in #if preprocessing directives, and this
>> expression shall have the same type as would an expression that is an
>> object of the corresponding type converted according to the integer
>> promotions."
>> That is, it is valid C to write '#if SIZE_MAX == 0xffffffff', while my
>> replacement fails that test:
>> foo.c:6:26: error: missing binary operator before token "("
>>  #define SIZE_MAX ((sizeof(char)) * -1)
>>                           ^
>> foo.c:7:5: note: in expansion of macro ‘SIZE_MAX’
> I tested this patch with a compile on OSX, and it does compile
> without warnings or errors. (NB: haven't tested that it
> fixes the warning that was being complained about in the
> other patchset.)
> I don't have a very strong opinion about whether it's the
> best fix, but a couple of thoughts:
>  * my inclination is to prefer not to override system
>    headers except where we've checked and know they're broken
>    (ie in a future world where Apple get their headers right
>    I'd rather we automatically ended up using their version
>    rather than ours)

That's a good point.

>  * we don't have any #if ...SIZE_MAX, but we do have some
>    for other kinds of _MAX constant.

reply via email to

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