Proof positive the "signedness of char *" warning is useless.

John Z. Bohach jzb at aexorsyst.com
Thu Dec 1 20:38:20 UTC 2005


On Thursday 01 December 2005 09:02, Rob Landley wrote:
> On Thursday 01 December 2005 10:14, Jason Schoon wrote:
> > > But what _might_ be useful is -funsigned-char added to our makefile.
>
> ...
>
> > This is the best solution I have heard thus far.  This is the path we
> > have always taken on our embedded platforms as well.
>
> Well, I just built it under 4.0.2 and it did at least keep the warnings
> down to a dull roar.  Still rather a lot of them.  (Attached.)  But nothing
> broke, so I'm checking it in.  (svn 12615)
>
> By the way, built with gcc 4.0.2, linked against uClibc (but not statically
> linked), an "allyesconfig" busybox (with mount NFS support and inetd RPC
> support disabled because my uClibc doesn't have that enabled) is 926632
> bytes.  For comparison, the exact same .config, built with gcc 3.3.5 and
> linked against glibc (but not static) is 963948 bytes.  (And yes, that's
> with the two things that need RPC support switched off).  So gcc 4.0 may
> have some downsides, but it has some upsides too...
>
> Rob

So I finally broke down and actually looked at the code...and yes, these are 
legitimate warnings.  When a function is prototyped as 

int foo(unsigned int x);

and it is used as 

...
int y,z;

y = foo(z);
...
then z and unsigned int x do in fact differ in signedness.  I thought your 
warnings were limited solely to char vs. unsigned char, but it seems to 
affect all...

I guess you all already knew this, but I'm surprised by the desire to sweep 
these warnings under the rug.  If you simply want to temporarily ignore these 
warnings so that more potentially serious warnings don't slip by, then I'm 
all for it, but if you want a long term solution, the code will have to be 
fixed, because signed != unsigned in a general sense.  To permanently hide 
these warnings is a bad idea.  IMHO.  I guess I don't believe that these 
warnings are useless, but it is likely that in this particular code base 
(busybox), it doesn't matter (currently).  However, future code may be 
affected by this, so I'd vote against it.  It might even be better to write a 
perl or gawk script to replaced the unsigned with signed in the cases where 
warnings are generated, and retest the code, since the signed is more 
restrictive...just an idea.

-- 
     ###  Any similarity between my views and the truth is completely ###
     ###  coincidental, except that they are endorsed by NO ONE       ###




More information about the busybox mailing list