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
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 dea
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
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_ imposi
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 r
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/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
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
d2963631dd54ddf0f46c151b7e3013e39bb78d
