qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings
Date: Wed, 16 Jan 2008 13:29:39 +0100	[thread overview]
Message-ID: <478DF8B3.1080909@linux.vnet.ibm.com> (raw)
In-Reply-To: <F18E75E0-C457-4A24-96E4-BB4F72F03C2F@pobox.com>

Hi,
the following discussion is from kvm-ppc-devel, but it is actually an qemu discussion so I move th topic to qemu-devel.
The original thread is cited in the mail below, in short the issue is the following:

Newer gcc versions generate warnings about implicit casts between different signed pointers.
That hits a lot of qemu code at least what I saw it compiling for ppc or x86.
So my question is, is there already a preferred qemu approach to get rid of these warnings
either the -Wno-pointer-sign solution like in the kernel or something else (I did not find
anything like that in the latest cvs snapshot or on this list)?

--- thread from kvm-ppc-devel ---

Jimi Xenidis wrote:
> 
> On Jan 11, 2008, at 10:04 AM, Hollis Blanchard wrote:
> 
>> 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. :(
>>
>>>[...]
>>
>> 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.
> 
> this is what:
> # disable pointer signed / unsigned warnings in gcc 4.0
> KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
> 
> In linux/Makefile is for.
> -JX

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

       reply	other threads:[~2008-01-16 12:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <47876B99.1000600@linux.vnet.ibm.com>
     [not found] ` <1200063861.5833.19.camel@basalt>
     [not found]   ` <F18E75E0-C457-4A24-96E4-BB4F72F03C2F@pobox.com>
2008-01-16 12:29     ` Christian Ehrhardt [this message]
2008-01-16 12:59       ` [Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings 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=478DF8B3.1080909@linux.vnet.ibm.com \
    --to=ehrhardt@linux.vnet.ibm.com \
    --cc=qemu-devel@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).