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 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.