From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945903AbXBHWDW (ORCPT ); Thu, 8 Feb 2007 17:03:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1945911AbXBHWDW (ORCPT ); Thu, 8 Feb 2007 17:03:22 -0500 Received: from smtp.osdl.org ([65.172.181.24]:41974 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1945903AbXBHWDV (ORCPT ); Thu, 8 Feb 2007 17:03:21 -0500 Date: Thu, 8 Feb 2007 14:03:06 -0800 (PST) From: Linus Torvalds To: =?ISO-8859-1?Q?J=2EA=2E_Magall=C3=B3n?= cc: Jan Engelhardt , Jeff Garzik , Linux Kernel Mailing List , Andrew Morton Subject: Re: somebody dropped a (warning) bomb In-Reply-To: Message-ID: References: <45CB3B28.60102@garzik.org> <20070208221317.5beedaeb@werewolf-wl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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