[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
Re: [Qemu-block] [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers
Tue, 12 Jul 2016 12:23:56 -0600
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 07/12/2016 09:21 AM, Eric Blake wrote:
> C99 requires SIZE_MAX to be declared with the same type as the
> integral promotion of size_t, but OSX mistakenly defines it as
> an unsigned long long expression even though size_t is only
> unsigned long. Rather than futzing around with whether size_t
> is 32- or 64-bits wide, let the compiler get the right type
> for us by virtue of integer promotion.
> See also https://patchwork.ozlabs.org/patch/542327/ for an
> instance where the wrong type trips us up if we don't fix it
> for good in osdep.h.
> Signed-off-by: Eric Blake <address@hidden>
> I can't test this on OSX, but I _did_ test that if I remove the
> '#ifdef __APPLE__' conditional (and just blindly do the redefine),
> things still compile on Linux (which means I got the type
> computation correct).
> This is my response to
> +/* Mac OSX has a <stdint.h> bug that incorrectly defines SIZE_MAX with
> + * the wrong type */
> +#ifdef __APPLE__
> +#undef SIZE_MAX
> +#define SIZE_MAX ((sizeof(char)) * -1)
I guess I over-parenthesized that, but I'm not sure if that alone is
worth a respin.
This violates POSIX, which requires that:
"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
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’
On the other hand, we don't have anything in current qemu sources that
uses SIZE_MAX inside #if.
I'd rather not worry about #if directives on a respin (other than to
enhance the commit message to document it as an intentional violation),
unless someone argues otherwise, because writing an expression that is a
preprocessor constant requires configure-time probing to determine the
type of ssize_t, which is a more complex task than the simpler
compile-time probing I did here. But I'll wait for a review before
deciding if a v2 is even needed (even if only to drop a redundant ()).
Oh, and by complete coincidence, I learned via a libvirt build failure
today that glibc has a similar bug to the OSX bug addressed here, but in
<limits.h> for SSIZE_MAX, and only on 32-bit platforms:
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Description: OpenPGP digital signature