[kvm-ppc-devel] The default for char Literals differ in signedness

[kvm-ppc-devel] The default for char Literals differ in signedness

[Christian Ehrhardt]

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 ?
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)?

Whats your opinion on that?

-- 

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

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

Re: [kvm-ppc-devel] The default for char Literals differ

[Hollis Blanchard]

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

Re: [kvm-ppc-devel] The default for char Literals differ in

[Jimi Xenidis]

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

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



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

[Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings

[Christian Ehrhardt]

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

Re: [Qemu-devel] Re: [kvm-ppc-devel] The default for char Literals differ in signedness between platforms causing us a lot of warnings

[Andre Przywara]

Christian,

 > 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)?

I fixed some of these issues in qemu at least for x86[1][2], those were 
commited mid of December[3] . I ported these over to Xen and posted it 
there[4]. I don't know what's the ultimate policy regarding these 
problems, my solution is:
1. Change the type whenever possible.
2. Introduce casts if 1. is not applicable or would introduce more 
back-castings.

Regards,
Andre.

[1] QEMU first proposal (all in one file) with comments:
http://lists.gnu.org/archive/html/qemu-devel/2007-11/msg00827.html
[2] QEMU reworked version (splitted up to address multiple issues)
http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00146.html
[3] QEMU commits:
http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00417.html
http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00420.html
http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00448.html
http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00452.html
[4] Xen devel post 
http://lists.xensource.com/archives/html/xen-devel/2008-01/msg00185.html

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy