From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 00:39:54 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 023911065673; Mon, 7 Nov 2011 00:39:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AF8588FC12; Mon, 7 Nov 2011 00:39:53 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pA70ajma062240 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 6 Nov 2011 17:36:45 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 6 Nov 2011 17:36:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> To: Rui Paulo X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 06 Nov 2011 17:36:45 -0700 (MST) Cc: Alexander Best , freebsd-toolchain@FreeBSD.org, Dimitry Andric Subject: Re: [poc] buildkernel + clang + -Werror X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 00:39:54 -0000 On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote: > The only argument against this tautological check that I agree with is = when the code is explicitly trying to be safe. If the developer checks = for "i < 0" when indexing an array he/she is trying to guard against = possible pitfalls in the future when someone suddenly decides to change = the variable type to become signed. One possible security vulnerability = was avoided because that developer checked for negative values. > I'm against turning this off by default, but it should not cause an = error. Except when you pass args back and forth between signed and unsigned and = back again. If you check < 0 in the middle, that's one more security = bug you thought you had fixed, but really you've done nothing with. Warner