compilation warnings: 'pointer targets ... differ in signedness'

Ihno Krumreich ihno at suse.de
Tue Oct 4 08:41:17 UTC 2005


On Sun, Sep 25, 2005 at 12:34:14AM -0500, Rob Landley wrote:
> On Saturday 24 September 2005 22:21, Mike Frysinger wrote:
> > not really ... sometimes it can safely be ignored, but globally adding
> > -funsigned-char is wrong ... if you're using a char and rely on it being
> > signed, -funsigned-char will break that
> 
> If you're using a char and relying on it being signed, that's never been 
> portable.  (I don't know if c99 finally got around to specifying it.)

The default handling for chars is as follows for the following architectures:

i386 - signed char
x86_64 - signed char

ppc/ppc64 - unsigned char
s390/s390x - unsigned char

The standard still says that the handling of chars (signed or unsigned)
is implementation specific.

So relying on the signedness of a char is a _very_ bad idea.

> 
> A normal character string is "char *".  I don't think a pointer to a string 
> literal is going to give you "unsigned char *", is it?  Yet I looked at 
> loop.c and the API was feeding strings into something defined in linux/loop.h 
> as "unsigned char *", and I went to great lengths to actually get us to the 
> point where we were using the proper #include for that because the 
> alternative was a nightmare.
> 
> Now we can stick in explicit casts to make the warnings shut up, but how is 
> that an improvement?

If possible dont use type casts. If used in the wrong place, you just
hide the possible bugs.

Ihno

-- 
Best regards/Mit freundlichen Grüßen

Ihno Krumreich

"Never trust a computer you can lift."
--
Ihno Krumreich            ihno at suse.de
SUSE LINUX Products GmbH  Projectmanager S390 & zSeries
Maxfeldstr. 5             +49-911-74053-439
D-90409 Nürnberg          http://www.suse.de



More information about the busybox mailing list