If somebody behaves like this it is her/his own fault and I certainly
won't trust the program. This whole discussion looks to me as if some
people fear the extra work caused by this. If the program is written
correctly casts are only necessary if to correct some misconceptions
in the language definition but this is really not frequent.
It's an awful lot of work. Right now it's very easy, with a very big
source tree (krb5 has literally hundreds of files), to scan the MAKELOG
file, and find warnings which need to be fixed. Given that I have many
folks continuously doing work on the source tree, and some of they
aren't using GCC, there's no way for me to know right now whether a
particular warning is spurious or not. Checking all possible warnings
each time I compile this huge source tree is simply and plainly
impossible.
Even with a package that's completely under my control, I don't want to
have to remember that a particular warning is meaningless --- how often
do *you* remember that line 415's signed/unsigned mismatch is harmless,
but line 750's signed/unsigned mismatch represents a real bug? And
remember, line numbers for a particular function move around!!
I'll repeat my original suggestion: #pragma's that tell GCC that a
particular function returns a type for which the signed/unsigned
warnings shouldn't be emitted. Otherwise, you do have a real mess
trying to figure out what's what.
Another suggestion might be programming GNU emacs to have a
M-x skip-meanless-flaming-worthless-gcc-warning-messages function.
The point is that one way or another, we need to suppress the false
positives, so that programmers can focus on the real warnings. The
whole point of programming tools is to make life easier for the
programmer, not harder.
- Ted