From: Eric Blake <eblake@redhat.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers
Date: Tue, 12 Jul 2016 12:23:56 -0600 [thread overview]
Message-ID: <578535BC.3000904@redhat.com> (raw)
In-Reply-To: <1468336912-20396-1-git-send-email-eblake@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]
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 <eblake@redhat.com>
> ---
>
> 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
> https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg02276.html
>
> +/* 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:
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’
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:
https://sourceware.org/bugzilla/show_bug.cgi?id=13575
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-07-12 18:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 15:21 [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers Eric Blake
2016-07-12 18:23 ` Eric Blake [this message]
2016-07-12 19:35 ` Peter Maydell
2016-07-12 20:22 ` Eric Blake
2016-07-13 7:50 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=578535BC.3000904@redhat.com \
--to=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).