From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bN2Lm-0001j5-C4 for qemu-devel@nongnu.org; Tue, 12 Jul 2016 14:24:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bN2Lk-00049G-12 for qemu-devel@nongnu.org; Tue, 12 Jul 2016 14:24:05 -0400 References: <1468336912-20396-1-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <578535BC.3000904@redhat.com> Date: Tue, 12 Jul 2016 12:23:56 -0600 MIME-Version: 1.0 In-Reply-To: <1468336912-20396-1-git-send-email-eblake@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3wG9o08RtQXVE8JeJ5w6hbjL72c7bSPcn" Subject: Re: [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3wG9o08RtQXVE8JeJ5w6hbjL72c7bSPcn From: Eric Blake To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, qemu-block@nongnu.org Message-ID: <578535BC.3000904@redhat.com> Subject: Re: [Qemu-devel] [PATCH] build: Work around SIZE_MAX bug in OSX headers References: <1468336912-20396-1-git-send-email-eblake@redhat.com> In-Reply-To: <1468336912-20396-1-git-send-email-eblake@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > Signed-off-by: Eric Blake > --- >=20 > 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). >=20 > This is my response to > https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg02276.html >=20 > +/* Mac OSX has a 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#ta= g_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 =3D=3D 0xffffffff', while m= y 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 =E2=80=98SIZE_MAX=E2=80=99 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 for SSIZE_MAX, and only on 32-bit platforms: https://sourceware.org/bugzilla/show_bug.cgi?id=3D13575 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --3wG9o08RtQXVE8JeJ5w6hbjL72c7bSPcn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXhTW8AAoJEKeha0olJ0NqBZ4IAJtC05NxjneDe5wK1gbetUZu cmZ/ZCuW3dGEZmJUVxfytof8IVU/VzdHcJKB0PgvJ/JfmtkpocjFqBd1VOmxtyOv QLL7BbolKvnSUnS3GTTmmGeGQ5C1rdX/wwU3ZiafgE/Bh0/XQvnC7OxkIpsUO2Wi 0kHKCR4HJPWXNk7tAs+vdkONvDbo04YlUOThTwI4zjr/LSAhHK938dxI6iPwH5RV 15vm844sOEbmkZEuowbkBQ8eevZskeaVVQYSu+/1FqD+WLxaGE74aO5+P4IpxS1k y1tOMsLFfuFIK2eZE3Eh9EvV2+/tRUzf7WwtDCQQSgFCd1jE1yEwbuERIATnRMQ= =3ZdM -----END PGP SIGNATURE----- --3wG9o08RtQXVE8JeJ5w6hbjL72c7bSPcn--