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

[Larry Doolittle]

Guys -

On Tue, Oct 04, 2005 at 12:22:54PM -0500, Rob Landley wrote:
> On Tuesday 04 October 2005 03:41, Ihno Krumreich wrote:
> > > 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.)
>  [example omitted]
> > So relying on the signedness of a char is a _very_ bad idea.
> ...
> > > 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.
> 
> This gets us back to telling the compiler what behavior we actually want, 
> which would be adding -funsigned-char to our makefile.

99% of what you do with chars has nothing to do with whether or
not they're signed.  The point of the C standard standing mute
on the default signedness is that the compiler can tune for whatever
is more efficient.  So in 99% of our uses, busybox should leave it
unspecified.

There are a few key cases where the signedness matters, and in
those cases you should specify: when you use it as an index to
an array (preferably when char is only 8 bits!) it needs to be
unsigned.  If you work with character codes greater than 127,
and write them numerically (like busybox's vi does with VI_K_UP,
for instance) they need to be unsigned.

Blanket declaration of all chars as unsigned (or signed, for that
matter) is, well, counter to the philosophy of C.

I could generate a patch that cleans up that part of busybox
according to my perspective.  Would anyone read it if I took the time?

     - Larry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/busybox/attachments/20051004/db03d98f/attachment-0002.pgp