From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3YI9-00021C-Vv for qemu-devel@nongnu.org; Tue, 23 Dec 2014 17:51:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3YI5-000184-Sz for qemu-devel@nongnu.org; Tue, 23 Dec 2014 17:51:01 -0500 Message-ID: <5499F1C5.6060206@redhat.com> Date: Tue, 23 Dec 2014 15:50:45 -0700 From: Eric Blake MIME-Version: 1.0 References: <1419373336-17800-1-git-send-email-peter.maydell@linaro.org> <1419373336-17800-3-git-send-email-peter.maydell@linaro.org> In-Reply-To: <1419373336-17800-3-git-send-email-peter.maydell@linaro.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CQ8MmNUK7DKatSKSbHqwWcd4NmXxVm76F" Subject: Re: [Qemu-devel] [PATCH 2/2] target-ppc: Cast ssize_t to size_t before printing with %zx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, Alexander Graf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CQ8MmNUK7DKatSKSbHqwWcd4NmXxVm76F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2014 03:22 PM, Peter Maydell wrote: > The mingw32 compiler complains about trying to print variables of type > ssize_t with the %z format string specifier. Since we're printing it > as unsigned hex anyway, cast to size_t to silence the warning. Hmm. I wonder if mingw headers are mixing 'long' and 'unsigned int' (or maybe 'unsigned long' and 'int') for the underlying definitions of 'ssize_t' vs. 'size_t'; both are 32-bits on the platform, but a difference in underlying type would definitely explain why you get a compiler warning if you use %zd with size_t or %zu with ssize_t. On the other hand, the warning I've most often seen is that native windows completely lacks %z support, so gcc is smart enough to warn that ANY use of %z is not going to work, for a function marked __attribute__((__printf__)) on mingw. >=20 > Signed-off-by: Peter Maydell > --- > I suspect that this is a compiler bug, but this is the only instance > in the codebase so I'm prepared to work around it to get to a point > where we can turn on warnings-as-errors for w32, because some of the > w32-specific errors really are flagging up issues we need to fix. With new enough mingw headers, the alternative solution is to guarantee that #__USE_MINGW_ANSI_STDIO is defined before including standard headers, then %z, %j, %lld, and other required constructs magically work (because you are no longer using the native printf, but the fixed mingw shim). Once you do that, you want to use __attribute__((__gnu_printf__)) instead of __attribute__((__printf__)) in order to teach gcc that yes, your use of %z is really going to work. For some more background reading: http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/ https://lists.gnu.org/archive/html/bug-gnulib/2014-12/msg00029.html > --- > hw/ppc/spapr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 08401e0..9aaa800 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1438,7 +1438,7 @@ static void ppc_spapr_init(MachineState *machine)= > } > if (spapr->rtas_size > RTAS_MAX_SIZE) { > hw_error("RTAS too big ! 0x%zx bytes (max is 0x%x)\n", > - spapr->rtas_size, RTAS_MAX_SIZE); > + (size_t)spapr->rtas_size, RTAS_MAX_SIZE); What's the actual compiler warning you got? This feels like it won't work if the real problem is the compiler telling you that %z is unknown; conversely, if it is a mismatch between 'size_t' vs. 'ssize_t', we probably ought to report it to the mingw folks to fix their environment to use the same underlying type for signed vs. unsigned sizes. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --CQ8MmNUK7DKatSKSbHqwWcd4NmXxVm76F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJUmfHFAAoJEKeha0olJ0NqxzwH/3RDZvclwKv1vuXflPtzvLfg aGHnG/JArxb7CLi8jci8gwmjZ44BfOLRApdTw7VLnGnxZhjnVpmUynpiJadC/Fq9 +IFx10XWupSEm7T/q5TZsuOkxOEd3DlmIMr9/ggFEb08j+JxX1StaTZOObMlEVlG ot/U01gbTDjL3WA4xvVEA+8F5Xb2AkTEKitNgU1f+wLKYEvTmYFilpe8NL1M6TY/ GW+tZ5v3SNJ98HAFRDjOy/UaUY0w4PjOsxcfH1uFWkIPvNlz+vdoS0cRhZ/rySX7 nZ+Qs7fvhivDo9zF2Jp41G88DvR1w26LwES5emHZBSxv9kzGiu4xYbuVWHyEHSA= =Lmsk -----END PGP SIGNATURE----- --CQ8MmNUK7DKatSKSbHqwWcd4NmXxVm76F--