From owner-svn-src-all@FreeBSD.ORG Mon Jan 23 04:30:09 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A6B0106566C; Mon, 23 Jan 2012 04:30:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id F05038FC0C; Mon, 23 Jan 2012 04:30:07 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q0N4Ts50002922; Mon, 23 Jan 2012 13:30:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q0N4Tm1X061049; Mon, 23 Jan 2012 13:29:50 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 23 Jan 2012 13:28:40 +0900 (JST) Message-Id: <20120123.132840.618925004528110765.hrs@allbsd.org> To: eadler@FreeBSD.org From: Hiroki Sato In-Reply-To: References: <201201200138.q0K1cSou016739@svn.freebsd.org> <20120120.123256.1432718473132856309.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Jan_23_13_28_40_2012_675)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 23 Jan 2012 13:30:05 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r230354 - head/usr.sbin/makefs X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 04:30:09 -0000 ----Security_Multipart(Mon_Jan_23_13_28_40_2012_675)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eitan Adler wrote in : ea> I was was unaware this code was contributed. I just looked at the ea> NetBSD version and I don't think it suffers from the same problem - ea> the loop appears to be used later. If that is because of some other Just checking, but the variables dot and semi are not used even in the NetBSD version since the initial import (in the NetBSD tree). What is "the same problem" you mentioned here? The problem I pointed out is just "removing the useless loop would be good but leaving the related comments is bad"... ea> bug fix which could be upstreamed that would be great. On the other ea> hand I would like to continue with my goal of making the non-contrib ea> world compilable with CC=gcc46. ea> ea> Should I revert this commit? I don't think it is needed. The makefs utility is a special case because it will probably diverge from the upstream to support FreeBSD-specific feature in the future (this is one of the reasons why it is not in contrib/). It didn't happen so far, however. By the way, does gcc46 no longer allow unused code? Generally speaking, I think it is enough to clean up unused code only when we actually change the code. -- Hiroki ----Security_Multipart(Mon_Jan_23_13_28_40_2012_675)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8c4fgACgkQTyzT2CeTzy1+pwCfWJuGJplAJB335qdB4fMrYY1Q clcAoNVXKwsVsjnHVVk0uxVcLDXtJ6OV =Qzz4 -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Jan_23_13_28_40_2012_675)----