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