[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.