From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Kevin Wolf <kwolf@redhat.com>, Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers
Date: Tue, 12 Jul 2016 14:22:51 -0600 [thread overview]
Message-ID: <5785519B.8080504@redhat.com> (raw)
In-Reply-To: <CAFEAcA_qtzmpLjMDvCbOtGbNnhGBNj054==j1fdyiKqpay=6dg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
On 07/12/2016 01:35 PM, Peter Maydell wrote:
> 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.)
Ultimately, the combination of this patch plus the block patchset in
question is where we prove if it makes a positive difference, so if you
do have a chance to test it on OSX, that would be nice. And that's true
whether we keep this version of the patch (with #if __APPLE__) or do a
second version based on a witness set at configure time, because the
interaction you're testing is if the replacement #define SIZE_MAX
silences the warning about printf(%zd).
>
> 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)
Indeed, a configure-based solution would avoid checkpatch.pl griping
about adding an #if __APPLE__.
And since glibc has the same bug with SSIZE_MAX, a configure-based
solution would be easier to copy-and-paste if we needed to work around
that too (then again, we don't have any use of SSIZE_MAX at the moment).
> * we don't have any #if ...SIZE_MAX, but we do have some
> for other kinds of _MAX constant.
I'll wait a bit longer to see if any other opinions surface, but sounds
like I'll probably be doing a v2 and trying for a configure solution.
--
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 20:23 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
2016-07-12 19:35 ` Peter Maydell
2016-07-12 20:22 ` Eric Blake [this message]
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=5785519B.8080504@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.