Re: [Qemu-block] [Qemu-devel] [PATCH v5] build: Work around SIZE_MAX bug in OSX headers
On Oct 11, 2016, at 2:12 PM, Eric Blake wrote: > On 10/11/2016 01:03 PM, Programmingkid wrote: > >>> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with >>> + * the wrong type. Our replacement isn't usable in preprocessor >>> + * expressions, but it is sufficient for our needs. */ >>> +#if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MAX >>> +#undef SIZE_MAX >>> +#define SIZE_MAX ((size_t)-1) >>> +#endif >>> + > >> I have applied your patch to the most recent git commit >> (627eae7d729277c84f8e0ac07a8caab39c92c38d) on Mac OS 10.6.8. QEMU built >> without any problems using gcc 4.9. > > Did you also tweak the code to make sure there was an instance of > printf("%zu", SIZE_MAX) (or similar)? It's not enough that it compiles > without complaint (although that helps), but also that the > compiler-warning-on-printf goes away (which we currently don't have any > in the tree, because we've been writing '"%zu", (size_t)SIZE_MAX' to > work around the broken headers). I saw no warnings when I added your printf code. The output was 18446744073709551615.
Re: [Qemu-block] [Qemu-devel] [PATCH v5] build: Work around SIZE_MAX bug in OSX headers
On 11 October 2016 at 19:12, Eric Blakewrote: > On 10/11/2016 01:03 PM, Programmingkid wrote: > >>> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with >>> + * the wrong type. Our replacement isn't usable in preprocessor >>> + * expressions, but it is sufficient for our needs. */ >>> +#if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MAX >>> +#undef SIZE_MAX >>> +#define SIZE_MAX ((size_t)-1) >>> +#endif >>> + > >> I have applied your patch to the most recent git commit >> (627eae7d729277c84f8e0ac07a8caab39c92c38d) on Mac OS 10.6.8. QEMU built >> without any problems using gcc 4.9. > > Did you also tweak the code to make sure there was an instance of > printf("%zu", SIZE_MAX) (or similar)? It's not enough that it compiles > without complaint (although that helps), but also that the > compiler-warning-on-printf goes away (which we currently don't have any > in the tree, because we've been writing '"%zu", (size_t)SIZE_MAX' to > work around the broken headers). I have made that check, and tested that the patch causes the resulting build failure to go away. I'll apply this to master... thanks -- PMM
Re: [Qemu-block] [Qemu-devel] [PATCH v5] build: Work around SIZE_MAX bug in OSX headers
On 10/11/2016 01:03 PM, Programmingkid wrote: >> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with >> + * the wrong type. Our replacement isn't usable in preprocessor >> + * expressions, but it is sufficient for our needs. */ >> +#if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MAX >> +#undef SIZE_MAX >> +#define SIZE_MAX ((size_t)-1) >> +#endif >> + > I have applied your patch to the most recent git commit > (627eae7d729277c84f8e0ac07a8caab39c92c38d) on Mac OS 10.6.8. QEMU built > without any problems using gcc 4.9. Did you also tweak the code to make sure there was an instance of printf("%zu", SIZE_MAX) (or similar)? It's not enough that it compiles without complaint (although that helps), but also that the compiler-warning-on-printf goes away (which we currently don't have any in the tree, because we've been writing '"%zu", (size_t)SIZE_MAX' to work around the broken headers). > > Reviewed-by: John Arbuckle> -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-block] [Qemu-devel] [PATCH v5] build: Work around SIZE_MAX bug in OSX headers
Eric Blakewrites: > 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 (which would be needed if we cared about > using SIZE_T in a #if expression), just hard-code it with a cast. > This is not a strict C99-compliant definition, because it doesn't > work in the preprocessor, but if we later need that, the build > will break on Mac to inform us to improve our replacement at that > time. > > 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. > > Some versions of glibc make a similar mistake with SSIZE_MAX; the > goal is that the approach of this patch could be copied to work > around that problem if it ever becomes important to us. > > Signed-off-by: Eric Blake Reviewed-by: Markus Armbruster