From owner-freebsd-arch@FreeBSD.ORG Fri Feb 6 18:51:13 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 055DB5B3 for ; Fri, 6 Feb 2015 18:51:13 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id BBECCC88 for ; Fri, 6 Feb 2015 18:51:12 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 166D6D6272D; Sat, 7 Feb 2015 05:51:06 +1100 (AEDT) Date: Sat, 7 Feb 2015 05:51:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Simon J. Gerraty" Subject: Re: Buggy sbspace() on 64bit builds? In-Reply-To: <2705.1423240024@chaos> Message-ID: <20150207053557.L3468@besplex.bde.org> References: <37282.1423208201@critter.freebsd.dk> <2705.1423240024@chaos> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=A5NVYcmG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=oikiVm-hFv82Gm5nFPsA:9 a=CjuIK1q_8ugA:10 Cc: Poul-Henning Kamp , Anuranjan Shukla , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:51:13 -0000 On Fri, 6 Feb 2015, Simon J. Gerraty wrote: > Poul-Henning Kamp wrote: >>> Any thoughts on what a fix should be for this? >> >> size_t or intptr_t ? > > I don't think so, the bug lies in the fact that on 64bit long is much > bigger than the uint's that are being manipulated. > Using a result object the same size works. Yes, using typedefed types just complicates the analysis, and size_t is unsigned so using it tends to give the same (un)sign extension bugs as using u_int. Most variables should be plain int. It is then implicit that the values are not too large positive or negative for expressions involving them to overflow. The subtraction here is especially easy to understand. Its terms must be nonnegative, so overflow can't happen. Its terms should also not be very large, but that is not needed here. If variables have an unsigned type (except possibly u_char or u_short), then everywhere that they are used the reader has to worry about them actually needing to be unsigned for the purpose of holding very large values or overflow not really being possible (it just gives the result modulo 2**N). The bug could also be fixed by changing everything to size_t. On 64-bit arches, that would waste 32 bits for all the fields in the struct, and it still needs delicate conversions to put differences in signed longs. Using a consistently wide type does give a better chance of the delicate conversions occurring accidentally. Bruce