From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH 2/2] target-ppc: Cast ssize_t to size_t before printing with %zx
Date: Tue, 23 Dec 2014 15:50:45 -0700 [thread overview]
Message-ID: <5499F1C5.6060206@redhat.com> (raw)
In-Reply-To: <1419373336-17800-3-git-send-email-peter.maydell@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]
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.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> 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(-)
>
> 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.
--
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:[~2014-12-23 22:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 22:22 [Qemu-devel] [PATCH 0/2] target-ppc: Fix clang and w32 warnings Peter Maydell
2014-12-23 22:22 ` [Qemu-devel] [PATCH 1/2] target-ppc: Mark SR() and gen_sync_exception() as !CONFIG_USER_ONLY Peter Maydell
2014-12-23 22:22 ` [Qemu-devel] [PATCH 2/2] target-ppc: Cast ssize_t to size_t before printing with %zx Peter Maydell
2014-12-23 22:36 ` Stefan Weil
2014-12-23 22:47 ` Peter Maydell
2014-12-24 9:47 ` Stefan Weil
2014-12-23 22:50 ` Eric Blake [this message]
2014-12-23 23:09 ` Peter Maydell
2014-12-23 23:25 ` [Qemu-devel] [PATCH 0/2] target-ppc: Fix clang and w32 warnings Alexander Graf
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=5499F1C5.6060206@redhat.com \
--to=eblake@redhat.com \
--cc=agraf@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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).