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

Rob Landley rob at landley.net
Thu Dec 1 23:13:59 UTC 2005


On Thursday 01 December 2005 14:38, John Z. Bohach wrote:
> 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...

My complaint was that any legitimate warnings were getting buried in the noise 
of all the char * warnings.

The "signedness of int" warnings are a lot more legitimate, because that's a 
signedness that was always well defined.

> 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,

Looking at several of the "signedness of char" warnings, the obvious solution 
was typecasts to shut the compiler up, which just pollutes the source.

> 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.

The compiler never previously generated these warnings and I've yet to see an 
actual bug uncovered by this, but it was only the char ones I was railing 
against as actively stupid.  Not the short, int, or long ones.

> 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.

Vote against what, defining the signedness of char to something consistent?  
Too late, I checked it in.

> 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,

NO.

Automatic changes to shut the compiler up, where a human didn't look at each 
and every change being made, are not just churn but DANGEROUS churn.  I would 
_protest_ the application of such a patch.

> and retest the code, 

Because obviously none of these are bugs that have shown up in testing so far, 
so fresh testing will obviously be equally effective in giving us a false 
sense of security.

Something _useful_ to do would be to fill out the test suite so we have 
serious coverage.  (Not necessarily fun, but I take a whack at it every 
couple of weeks.  Big job, but relatively easy to make progress on.  The 
problem is, I generally find esoteric bugs and wander off on tangents fixing 
them. :)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.



More information about the busybox mailing list