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

John Z. Bohach jzb at
Fri Dec 2 05:13:26 UTC 2005

On Thursday 01 December 2005 15:13, Rob Landley wrote:

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

All such warnings are "legitimate."  If a function asks you to pass to it a 
signed parameter, and you pass it an unsigned one, be warned.  If its 
intential, cast it, so its obvious that the type mismatch is intentional.  If 
its not intentional, fix it to match the prototype.

You've taken the position that because nothing is obviously broken by 
sign-mismatched parameters being passed, its okay to do so.  It is not okay, 
even though most of the time you can get away with it, and most of the time 
compilers don't warn about it.

Now, the current situation is that gcc has reached a level of maturity (or the 
gcc developers had nothing better to do) that allows it to warn about sign 
mismatches.  I applaude that.  Yes, C is a weakly-typed language, else such 
mismatches would cause compile-time errors and your code wouldn't even 
compile.  I admit to being a purist, but damn it, computing requires, nay, 
demands, perfection.  Yes, back-end testing could catch some errors, but if 
you write clean code to begin with, you won't need to rely so much on the 

Your points are very valid, if taken in the context of "do we want to allocate 
resources to implement the _proper_ fix to the sign warning  when nothing 
seems to be broken anyway."  And in that context, I agree with you 100%.

Note that _proper_ means to me to use either casts if the mismatch is 
intentional, or fixed code if the type mismatch is not intentional.  I mean, 
if the prototype says "pass me a signed char" than just humor the man and 
pass him a signed char, and don't squirm about "well a char's signedness has 
never really been well-defined..."  While you are correct, I'd like to point 
out to the court that your argument is irrelevant to clean code.  If you 
don't like warnings, write clean code.  If your argument is it doesn't 
matter, then fine, we're with you.  But grant me that you wouldn't do 
sign-mismatched parameters on purpose...(at least not without a cast.)  And 
if its not on purpose, than again, I want the compiler warnings, so I can go 
back and clean my code, because maybe I did miss something...

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

There are lots of such warnings.  They all need to be looked at and fixed 
manually in the end.  The destination is the same.  There's a top-down 
approach, of starting with the first and going on and on...and than there's 
the bottom up approach:  replace them all let the test suite sort them out.  
Depending on the circumstances, one approach may be more appropriate than the 

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

You misunderstand.  If there are no errors (you claim there are none) with the 
sign mismatches, then fixing them to be not mismatched will introduce them?  
Doesn't follow, unless the code relies on coding errors to come up with the 
correct results.  Possible, but not likely.  If this code works with the 
warnings, surely there can't be too much risk in fixing the warnings 
correctly, to have not sign mismatched parameters?  Can there?  Yes, I know 
your answer, but if it is a risk, then I submit its a greater risk to have 
the sign mismatches present in the first place.  Resources resources...

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

Can't blame programmers not honoring the prototype on either the compiler or 
the test suite.  Damn it people, honor thy father, mother, and prototype.

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

I'm quite swamped with a bunch of projects at the moment, but soon, soon I 
tell you, I will be able to contribute more than just words...I'm cleaning up 
buildroot, among other things, to be at least self-hosting, and when that's 
done, I can write some code for busybox.  Keep me in mind, and if there's 
some coding you want to offload later, I'd be happy to help.  And by the way, 
I NEVER mismatch signs on prototypes, except when hardware bit-mapped 
structures force me to recast bit-fields, but then I ALWAYS cast them, so I 
know I did it on purpose.  And my bain is the miserable "blah blah breaks 
strict-aliasing rules..." warning which showed up around the gcc-3.3.4 
timeframe.  Yes, I could turn it off easily, but I've learned to live with 
it, even though I am quite a huge fan of the silent build (and I don't mean 
with the .SILENT target), i.e., no warnings, none, not even a makefile 
warning about overriding rules, though I really can't do anything about that 
without modifying the 'make' sources...(which I've considered...).


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