From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 25 11:01:01 2005 Return-Path: X-Original-To: FreeBSD-hackers@freebsd.org Delivered-To: FreeBSD-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02B1116A41F for ; Sun, 25 Sep 2005 11:01:01 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43C4C43D49 for ; Sun, 25 Sep 2005 11:00:59 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from flame.pc (patr530-a133.otenet.gr [212.205.215.133]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j8PB0axC024086; Sun, 25 Sep 2005 14:00:36 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8PB06et000928; Sun, 25 Sep 2005 14:00:06 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8PB054n000927; Sun, 25 Sep 2005 14:00:05 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sun, 25 Sep 2005 14:00:05 +0300 From: Giorgos Keramidas To: Frank Mayhar Message-ID: <20050925110005.GB819@flame.pc> References: <1127618793.38683.9.camel@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127618793.38683.9.camel@realtime.exit.com> Cc: FreeBSD-hackers@freebsd.org Subject: Re: Oddity in libufs. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 11:01:01 -0000 On 2005-09-24 20:26, Frank Mayhar wrote: > I've been using libufs as the I/O mechanism for my (heavy) modification > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > other bits and pieces to maybe get it suitable for release into the > wild. I just looked at cgread() to see what it does and noticed that > there seems to be a redundant line: > > . > . > if (c >= fs->fs_ncg) { > return (0); > } > ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize; > if (bread(disk, fsbtodb(fs, cgtod(fs, c)), disk->d_cgunion.d_buf, > . > . > > That assignment up there looks redundant, as ccg is never used. I > suspect that it's a relic of an old lseek()/read() pair that's long > gone. It's probably easy to verify that without this assignment 'ccg' is an unused var: - Comment it out - Rebuild with an elevated WARNS level if a warning about 'unused ccg var' is printed, then you are certain that ccg was only used for the assignment.