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
