From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNSj-0006Jr-C5 for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuNSg-0006rG-1o for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:32:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNSf-0006r6-St for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:32:29 -0500 References: <1446740339-31366-1-git-send-email-pmorel@linux.vnet.ibm.com> From: Paolo Bonzini Message-ID: <563B8498.7070804@redhat.com> Date: Thu, 5 Nov 2015 17:32:24 +0100 MIME-Version: 1.0 In-Reply-To: <1446740339-31366-1-git-send-email-pmorel@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/7] int128: reparing broken 128 bit memory calculations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Morel , qemu-devel@nongnu.org Cc: cornelia.huck@de.ibm.com, peter.maydell@linaro.org On 05/11/2015 17:18, Pierre Morel wrote: > The size of a memory area can never be negative. > It follows it must be defined as an unsigned value. > > Let's modify the memory regions size to unsigned 128 integer > and modify accordingly the 128 bit arithmetic. > > This makes memory size calculations easier and easier to understand. > > I fear loud protest but really, it is a broken concept that > obfuscate the code. You are right in fearing loud protest, though the protest is for the lack of explanation of what is broken. Since the values are never going to be > 2^65, there is no chance of overflow. On the other hand there are cases where we compute start+size-1, and size-1 *could* overflow if you use unsigned integers. So I am not sure... why? Paolo