On 10/18/2011 03:38 AM, David Gibson wrote:
On Mon, Oct 17, 2011 at 12:34:19PM +0200, Avi Kivity wrote:
On 10/17/2011 07:31 AM, David Gibson wrote:
In terms of how the code looks, it's seriously more ugly (see the
patches I sent out). Conceptually it's cleaner, since we're not
On 10/17/2011 07:31 AM, David Gibson wrote:
In terms of how the code looks, it's seriously more ugly (see the
patches I sent out). Conceptually it's cleaner, since we're not dodging
the issue that we need to deal with a full 64-bit domain.
We don't have to dodge that issue. I know how
On Mon, Oct 17, 2011 at 12:34:19PM +0200, Avi Kivity wrote:
On 10/17/2011 07:31 AM, David Gibson wrote:
In terms of how the code looks, it's seriously more ugly (see the
patches I sent out). Conceptually it's cleaner, since we're not dodging
the issue that we need to deal with a
On 10/12/2011 04:37 AM, David Gibson wrote:
The memory API currently manipulates address range start and size values
as signed integers. Because memory ranges with size INT64_MAX are very
common, we must be careful to to trigger integer overflows. I already
fixed such an integer overflow bug
On Sun, Oct 16, 2011 at 11:56:03AM +0200, Avi Kivity wrote:
On 10/12/2011 04:37 AM, David Gibson wrote:
[snip]
static AddrRange addrrange_intersection(AddrRange r1, AddrRange r2)
{
-int64_t start = MAX(r1.start, r2.start);
-/* off-by-one arithmetic to prevent overflow */
-
On 10/16/2011 01:40 PM, David Gibson wrote:
Let me see if I can work up a synthetic int128 type.
So.. you think replacing every single basic arithmetic operations with
calls to implement the synthetic type, _and_ imposing the resulting
overhead is _less_ ugly than some slightly fiddly
On Sun, Oct 16, 2011 at 02:35:37PM +0200, Avi Kivity wrote:
On 10/16/2011 01:40 PM, David Gibson wrote:
Let me see if I can work up a synthetic int128 type.
So.. you think replacing every single basic arithmetic operations with
calls to implement the synthetic type, _and_ imposing the
The memory API currently manipulates address range start and size values
as signed integers. Because memory ranges with size INT64_MAX are very
common, we must be careful to to trigger integer overflows. I already
fixed such an integer overflow bug in commit
