Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964898AbWEJVdp (ORCPT ); Wed, 10 May 2006 17:33:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964913AbWEJVdp (ORCPT ); Wed, 10 May 2006 17:33:45 -0400 Received: from gateway-1237.mvista.com ([63.81.120.158]:4455 "EHLO gateway-1237.mvista.com") by vger.kernel.org with ESMTP id S964898AbWEJVdp (ORCPT ); Wed, 10 May 2006 17:33:45 -0400 Subject: Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix From: Daniel Walker To: Al Viro Cc: Steven Rostedt , Adrian Bunk , Alan Cox , akpm@osdl.org, linux-kernel@vger.kernel.org In-Reply-To: <20060510212058.GE27946@ftp.linux.org.uk> References: <1147257266.17886.3.camel@localhost.localdomain> <1147271489.21536.70.camel@c-67-180-134-207.hsd1.ca.comcast.net> <1147273787.17886.46.camel@localhost.localdomain> <1147273598.21536.92.camel@c-67-180-134-207.hsd1.ca.comcast.net> <20060510162404.GR3570@stusta.de> <1147290577.21536.151.camel@c-67-180-134-207.hsd1.ca.comcast.net> <1147295515.21536.168.camel@c-67-180-134-207.hsd1.ca.comcast.net> <20060510212058.GE27946@ftp.linux.org.uk> Content-Type: text/plain Date: Wed, 10 May 2006 14:33:42 -0700 Message-Id: <1147296822.21536.175.camel@c-67-180-134-207.hsd1.ca.comcast.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1256 Lines: 34 On Wed, 2006-05-10 at 22:20 +0100, Al Viro wrote: > On Wed, May 10, 2006 at 02:11:54PM -0700, Daniel Walker wrote: > > > I really don't see why it couldn't be added. What's the problem with it? > > > > > > I mean, I see lots of advantages, and really no disadvantages. > > Your vision is quite selective, then. > > > We are in complete agreement .. The only disadvantage is maybe we cover > > up and real error > > ... which is more than enough to veto it. However, that is not all. > Consider the following scenario: > > 1) gcc gives false positive > 2) tosser on a rampage "fixes" it > 3) code is chaged a month later > 4) a real bug is introduced - one that would be _really_ visible to gcc, > with "is used" in a warning > 5) thanks to aforementioned tosser, that bug remains hidden. I don't really see anything new here .. The same sort of stuff can happen in any code considered for inclusion .. That's what the review process is for . Real errors can be covered up any number of way .. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/