From owner-freebsd-toolchain@FreeBSD.ORG Mon Nov 7 00:47:38 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 12ACE1065672; Mon, 7 Nov 2011 00:47:38 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from stark.strangled.net (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id EB7FD8FC28; Mon, 7 Nov 2011 00:47:37 +0000 (UTC) Received: from [10.0.10.6] (c-71-204-150-235.hsd1.ca.comcast.net [71.204.150.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by stark.strangled.net (Postfix) with ESMTPSA id 9FBCE3981E; Sun, 6 Nov 2011 16:47:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> Date: Sun, 6 Nov 2011 16:47:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111105102102.GA54596@freebsd.org> <20111106172835.GO2258@hoeg.nl> <20111106203316.GA73216@freebsd.org> <4EB6F38E.2080006@FreeBSD.org> <20111106205805.GA78142@freebsd.org> <242747B7-3EAE-4988-A975-DC58B0997A6F@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) 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:47:38 -0000 On Nov 6, 2011, at 4:36 PM, Warner Losh wrote: > 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. >=20 > 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. Of course, but in the context of the compiler checks this argument = doesn't apply. Regards, -- Rui Paulo