directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Long comparisons
Date Wed, 23 Jan 2008 01:49:33 GMT
if these are really unsigned longs and we actually need a  <  
comparison then I dont think starting with LONG.MIN will help.... I  
really think looking at the 4 cases for mapping unsigned longs into  
longs will work better.

david jencks

On Jan 22, 2008, at 4:49 PM, Alex Karasulu wrote:

> Hi Emmanuel,
>
> On Jan 22, 2008 7:24 PM, Emmanuel Lecharny <elecharny@gmail.com>  
> wrote:
> Hi guys,
>
> yesturday and today, I fight against a vicious bug for hours.  
> Thanks to
> Pierre-Arnaud and Alex, I found the reason for the failures I was
> experienced.
>
> I empathize with your pain.  BTW I did very little to help.
>
> However after reading your post I considered just the high level  
> picture and here's what I thought:
>
> (1) these longs are ids to identify uniquely each entry in a BTree  
> based backend
> (2) the master table contains a durable sequence which is used to  
> generate these values and it presently starts the sequence at 1
> (3) JDBM or other BTrees don't care if the Long ID is positive or  
> negative as long as it is unique for each entry in the partition's  
> master table
> (4) When you do comparisons with subtraction (x - y) to see if  
> something is greater than 0 or not in a comparator you don't know  
> if x is bigger or smaller so you cannot determine if overflows will  
> result.
>
> You might be able to fix this in two ways.  First you can fix the  
> comparator to consider buffer overflow and just not use  
> subtraction.  You can just check if one Long is bigger than another  
> and return 0, -1, or 1 based on the comparisons.  I guess both  
> these mechanisms work.
>
> Another thing to consider out side of fixing the comparator is to  
> start the sequence at LONG_MIN instead of zero.
>
>
> What happened is that the Key used to extract an entry from the master
> table was compared with the stored Keys using a compare() method which
> uses long, doing some simple if ( key1 > key2 ) then ... test.
>
> This is obviously wrong if we are working with unsigned longs, because
> Java does not treat longs as unsigned, so -1 is always > to any  
> positive
> value (because the upper bit is 1 for negative values), but java >
> operator does not take this bit into account.
>
> After a convo with David Jencks, we agreed that we need a four steps
> comparison :
>
> if ( x >= 0 and y >=  0) then return x > Y
> if ( x < 0 and y >= 0) then return x
> if ( x >= 0 and y < 0) then return y
> if ( x < 0 and y < 0) then return -x < -y
>
> I thought for the Comparator you have to return 0, -1, 1.
>
> Alex
>


Mime
View raw message