From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Fri, 11 Jan 2008 15:04:21 +0000 Subject: Re: [kvm-ppc-devel] The default for char Literals differ Message-Id: <1200063861.5833.19.camel@basalt> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org 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