From: Hollis Blanchard <hollisb@us.ibm.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: [kvm-ppc-devel] The default for char Literals differ
Date: Fri, 11 Jan 2008 15:04:21 +0000 [thread overview]
Message-ID: <1200063861.5833.19.camel@basalt> (raw)
On Fri, 2008-01-11 at 14:14 +0100, Christian Ehrhardt wrote:
> Hi,
> maybe its an issue of my build environment only, but when I compile
> kvm-userspace for our platform I see a lot of warnings like that in
> the qemu code:
>
> warning: pointer targets in passing argument 3 of
> 'PPC_NVRAM_set_params' differ in signedness
>
> The reason is that some code defines function prototypes and variables
> with the type "const unsigned char*" and then assigns a literal like
> "PPC" to it. But per default our platform seems to have "const signed
> char*" for literals and so we get a lot of annoying warnings. E.g.
> nearly every line in qemu/target-ppc/translate.c.
>
> Should we do anything to prevent these Warnings or do you even see
> those ?
That warning only appears in recent versions of gcc. In fact I believe
there are 3 different types: char *, unsigned char *, and signed char *,
and implicitly casting between them generates the warnings. :(
> We could search for compiler options like
> -fsigned-string/-funsigned-string (did not help here in a quick test)
> or patch qemu code to our signedness, but this would need extensive
> tests to prevent that we fix it for us and create the same warning for
> others.
> The gcc developers here said a literal is defined as "array of char"
> which obviously can be cast implicitly to "const char*" and the
> platform decides if it is signed or unsigned - at least most library
> functions solve this by using "const char*" without signedness. That
> way the compilation should work for everyone because the
> variables/prototypes are automatically mapped to the platform defined
> signedness as the literals are too.
>
> The questions for our project are:
> - do we need that fixed?
> - is it our job to fix that?
> - Which approach should we go (maybe I missed some possible
> solutions)?
It's a qemu issue. If you want to fix it, you should bring it up on
qemu-devel and see what they think about it.
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
next prev reply other threads:[~2008-01-11 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-11 13:14 [kvm-ppc-devel] The default for char Literals differ in signedness Christian Ehrhardt
2008-01-11 15:04 ` Hollis Blanchard [this message]
2008-01-11 16:16 ` [kvm-ppc-devel] The default for char Literals differ in Jimi Xenidis
2008-01-16 12:29 ` [Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings Christian Ehrhardt
2008-01-16 12:59 ` Andre Przywara
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=1200063861.5833.19.camel@basalt \
--to=hollisb@us.ibm.com \
--cc=kvm-ppc@vger.kernel.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.