Proof positive the "signedness of char *" warning is useless.
John Z. Bohach
jzb at aexorsyst.com
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,
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