Re: somebody dropped a (warning) bomb

On Thu, Feb 08, 2007 at 02:03:06PM -0800, Linus Torvalds wrote:


On Thu, 8 Feb 2007, Linus Torvalds wrote:

But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
implementation-defined, so if you call "strcmp()", you are already
basically saying: I don't care (and I _cannot_ care) what sign you are
using.

Let me explain it another way.

Say you use

signed char *myname, *yourname;

if (strcmp(myname,yourname) < 0)
printf("Ha, I win!\n")

and you compile this on an architecture where "char" is signed even
without the explicit "signed".

What should happen?

Should you get a warning? The types really *are* the same, so getting a
warning sounds obviously insane. But on the other hand, if you really care
about the sign that strcmp() uses internally, the code is wrong *anyway*,
because with another compiler, or with the *same* compiler on another
architecture or some other compiler flags, the very same code is buggy.

In other words, either you should get a warning *regardless* of whether
the sign actually matches or not, or you shouldn't get a warning at all
for the above code. Either it's buggy code, or it isn't.

Warning only when the sign doesn't _happen_ to match is crap. In that
case, it's not a warning about bad code, it's a warning about a bad
*compiler*.

My suggestion is that if you *really* care about the sign so much that you
want the sign warning, make it really obvious to the compiler. Don't ever
call functions that have implicit signs. Make even "int" arguments (which
is well-defined in its sign) use "signed int", and then you can make the
compiler warn if anybody ever passes it an "unsigned int".

Never mind even a pointer - if somebody actually took the time and effort
to spell out "signed int" in a function prototype, and you pass that
function an unsigned integer, maybe a warning is perfectly fine. Clearly
the programmer really cared, and if he didn't care about the sign that
much, he could have used just "int".

Conversely, if somebody has a function with a "unsigned int" prototype,
and you pass it a regular "int", a compiler shouldn't complain, because an
"int" will just silently promote to unsigned. But perhaps the programmer
passes it something that he had _explicitly_ marked with "signed int".
Would it make sense to warn then? Makes sense to me.

And no, none of this is about "strict C standards". All of it is about
"what makes sense". It simply doesn't make sense to complain about the
sign of "char", because it's not something that has a very hard
definition. Similarly, you shouldn't complain about regular "int"
conversions, because they are normal, and the standard defines them, but
maybe you can take a hint when the programmer gives you a hint by doing
something that is "obviously unnecessary", like explicitly saying that
"signed int" thing.

Just an idea.

Linus

I perfectly agree with your analysis here. I'm used to specify "signed"
or "unsigned" when I really expect such a sign, whether it's an int or
char, and because of this, I've spent a lot of time stuffing useless
casts everywhere to shut stupid warning with common functions such as
strcmp(), or even my functions when I don't care about the sign. IOW,
the compiler's excessive warnings discourage you from being strict on
your types. That could be called "funny" if it did not make us waste
so much time.

I would really like to get the "I don't care" possibility by default.

Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: error
    ... foo.c:50: warning: string constant runs past end of line ... foo.c:7: warning: declaration of `n' shadows global declaration ... foo.c:29: warning: return type of `main' is not `int' ... char check(int n_, ...
    (comp.lang.c)
  • Re: somebody dropped a (warning) bomb
    ... But THE CALLER CANNOT AND MUST NOT CARE! ... warning sounds obviously insane. ... because with another compiler, or with the *same* compiler on another ... Make even "int" arguments (which ...
    (Linux-Kernel)
  • Re: gets() is dead
    ... a warning enabled on the various servers I have some control over, ... Unconditionally convert any call to getsto a warning message ... char *options; ... int mode; ...
    (comp.lang.c)
  • Re: Compile Time Error ... arghh
    ... foo.c:12: warning: function declaration isn't a prototype ... foo.c:13: warning: implicit declaration of function `malloc' ... int ccarray_destroy; ... char *dupstr; ...
    (comp.lang.c)
  • Re: please help with mysterious error....
    ... to an array of 10 char - instead of char *, which is what you get when you pass the name of an array of char to a function. ... warning: passing argument 1 of fseek discards qualifiers from pointer ... void int_fillinnumbers(int fillvalue, int startx, ... The fix here is: don't use nasty/stupid unsigned/signed-tricks! ...
    (comp.lang.c)
Loading