From owner-cvs-all Fri May 3 12:44:33 2002 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 81DA837B41D; Fri, 3 May 2002 12:44:24 -0700 (PDT) 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 FAA20309; Sat, 4 May 2002 05:44:21 +1000 Date: Sat, 4 May 2002 05:45:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "J. Mallett" Cc: cvs-committers@FreeBSD.ORG, Subject: Re: cvs commit: src/usr.bin/xargs xargs.c In-Reply-To: <20020502225801.GA10310@FreeBSD.ORG> Message-ID: <20020504052140.T8741-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 Thu, 2 May 2002, J. Mallett wrote: > On Fri, May 03, 2002 at 07:30:44AM +1000, Bruce Evans wrote: > > On Wed, 1 May 2002, J. Mallett wrote: > > > > > jmallett 2002/05/01 22:21:35 PDT > > > > > > Modified files: > > > usr.bin/xargs xargs.c > > > Log: > > > __COPYRIGHT() and __SCCSID(). > > > > These should never be used. They create conflicts for future imports > > and enlarge diffs with the vendor version by editing vendor lines, > > and using __COPYRIGHT demonstrates a bug in its implementation: > > Sorry about this. I'll back out SCCSID and COPYRIGHT usage here, as well > as m4(1), tomorrow. Sorry to pick on you. Perhaps a better example of messing with the vendor copyright string is in login/login.c. The string was first commented out and replaced by a quite different string generated by , and later the commented out code was removed. IMO, is only right for the kernel, but since it is only used in one place in the kernel, it shouldn't exist as a separate header. would be better if it added to existing copyright strings instead of replacing them. > Speaking of the updates in m4, one of them related to... > > int getreql() > { > int getreql; > ... > > Because of the shadowing. Changes like that are legitimate right? As it is, ITYM eqrel()/eqrel. Changing eqrel to eqrelval is OK, but I think you could find a better variable name. eqrelval is not a value; it is a code for the operator. The left and right operands are values; these are named vl and vr. The code also abuses vl to hold the result. (The result is a boolean (vl OP vr) where OP is the operand that is encoded by eqrelval.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message