From owner-cvs-all Mon Oct 21 19:10:53 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0DCE37B401; Mon, 21 Oct 2002 19:10:51 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 351CE43E6A; Mon, 21 Oct 2002 19:10:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id MAA31723; Tue, 22 Oct 2002 12:10:47 +1000 Date: Tue, 22 Oct 2002 12:21:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Mike Barcroft Cc: Poul-Henning Kamp , , Subject: Re: cvs commit: src/sys/i386/isa npx.c In-Reply-To: <20021021100136.B80691@espresso.q9media.com> Message-ID: <20021022121251.G12991-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 21 Oct 2002, Mike Barcroft wrote: > Poul-Henning Kamp writes: > > In message <20021021093912.A80691@espresso.q9media.com>, Mike Barcroft writes: > > >Can your lint define a constant that is in the implementation > > >namespace (eg. _LINT)? This would at least improve your change to > > >i386's which breaks things if an application > > >happens to `#define lint' in a C90 environment. > > > > Ohh, absolutely, that would be no problem at all. > > > > The problem is that "lint" is our standard for this: > > > > bang# sh /root/gsys lint | grep '#' | grep -v compile | wc -l > > 299 > > bang# sh /root/gsrc lint | grep '#' | grep -v compile | wc -l > > 5558 > > > > I'm not particularly attached to "lint", it can be any symbol we > > decide on, as long as we use the same one all over... > > Yes, but this is the second time ever "lint" has been used in a > standard header or in a header a standard header includes. The first > was in about a month ago, but since it only modifies > macros in the implementation namespace it isn't a problem. The first is a problem, and is therefore not present in my version, since it breaks lint's detection of syntax errors like __packed and __alligned(). Syntax errors like __unused are not so bad provided they are restricted to implementation details since __unused doesn't change the semantics. The change that added these also has style bugs (unsorting of a sorted list and code no longer matching its comment). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message