From owner-freebsd-arch@FreeBSD.ORG Fri Jan 28 18:51:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B0316A4CE for ; Fri, 28 Jan 2005 18:51:34 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC94943D41 for ; Fri, 28 Jan 2005 18:51:01 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0SInJB1010409; Fri, 28 Jan 2005 11:49:20 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Jan 2005 11:49:19 -0700 (MST) Message-Id: <20050128.114919.71097322.imp@bsdimp.com> To: paul@originative.co.uk From: Warner Losh In-Reply-To: <20050128173327.GI61409@myrddin.originative.co.uk> References: <20050128173327.GI61409@myrddin.originative.co.uk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG Subject: Re: c99/c++ localised variable definition X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2005 18:51:34 -0000 > So, are we going to start allowing this feature to be used in FreeBSD > since it would require a pretty major change to style(9). People differ as to the efficacy of such usage. Either they love it and can't understand why people wouldn't want to see definitions close to where they are used. Or they hate it and can't understand why you'd want to go searching for a definition when the one, true, god-given place is at the top of the function. Often times, no further discourse is possible because both sides know they are right, and the other side is a bunch of butt picking monekys that clearly should get out of the stone age... > I noticed when trying to use this feature that we're not running > the compiler with c99 fully supported yet so I guess that's perhaps > the first step to discuss. That's a reasonable thing to try to do, but it also opens up a number of side issues. We have already seen a taste of this in the WARNS=x efforts where people make it warns friendly to c99, only to discover that the system default is c89 and the fixes cause warnings/errors. Warner