From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946524AbXBIP6V (ORCPT ); Fri, 9 Feb 2007 10:58:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946555AbXBIP6V (ORCPT ); Fri, 9 Feb 2007 10:58:21 -0500 Received: from smtp.osdl.org ([65.172.181.24]:57121 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946524AbXBIP6U (ORCPT ); Fri, 9 Feb 2007 10:58:20 -0500 Date: Fri, 9 Feb 2007 07:58:00 -0800 (PST) From: Linus Torvalds To: Sergei Organov cc: =?ISO-8859-1?Q?J=2EA=2E_Magall=C3=C2=B3n?= , Jan Engelhardt , Jeff Garzik , Linux Kernel Mailing List , Andrew Morton Subject: Re: somebody dropped a (warning) bomb In-Reply-To: <87abznsdyo.fsf@javad.com> Message-ID: References: <45CB3B28.60102@garzik.org> <20070208221317.5beedaeb@werewolf-wl> <87abznsdyo.fsf@javad.com> 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 Fri, 9 Feb 2007, Sergei Organov wrote: > > As far as I can read the C99 standard, the "char", "signed char", and > "unsigned char", are all different types: Indeed. Search for "pseudo-unsigned", and you'll see more. There are actually cases where "char" can act differently from _both_ "unsigned char" and "signed char". > If so, then the code above is broken no matter what representation of > "char" is chosen for given arch, as strcmp() takes "char*" arguments, > that are not compatible with either "signed char*" or "unsigned char*". ..and my argument is that a warning which doesn't allow you to call "strlen()" on a "unsigned char" array without triggering is a bogus warning, and must be removed. Which is all I've ever said from the beginning. I've never disputed that "char" and "unsigned char" are different types. They *clearly* are different types. But that doesn't make the warning valid. There is a real need for NOT warning about sign differences. But this argument has apparently again broken down and become a "language lawyer" argument instead of being about what a reasonable compiler actually can and should do. As long as gcc warns about idiotic things, the kernel will keep shutting that warning off. I'd _like_ to use the warning, but if the gcc implementation is on crack, we clearly cannot. There's simply an issue of "quality of implementation". In the case of this warning, gcc is just not very high quality. Linus