Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end()

[Avi Kivity <avi@redhat.com>]

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 to remove the
> requirement for intermediate negative values, I just haven't made up a
> patch yet.  With that we can change to uint64 and cover the full 64
> bit range.  In fact I think I can make it so that size==0 represents
> size=2^64 and even handle the full 64-bit, inclusive range properly.

That means you can't do a real size == 0.

> > But my main concern is maintainability.  The 64-bit blanket is to short,
> > if we keep pulling it in various directions we'll just expose ourselves
> > in new ways.
>
> Nonsense, dealing with full X-bit range calculations in X-bit types is
> a fairly standard problem.  The kernel does it in VMA handling for
> one.  It just requires thinking about overflow cases.

We discovered three bugs already (you found two, and I had one during
development).  Even if it can probably be done with extreme care, but is
it worth spending all that development time on?

I'm not sure there is a parallel with vmas, since we're offsetting in
both the positive and negative directions.

-- 
error compiling committee.c: too many arguments to function