Re: ordered indexing for integers
Hallvard B Furuseth wrote:
Howard Chu writes:
> This code is wrong:
> (..)
> On most 32 bit machines the "if( chop ...)" comparison must always
> fail, since ber_slen_t is only 32bits. You should do the test before
> multiplying chop by 3.
No, chop already fits in ber_slen_t, since it is a ber_len_t/7*3.
The check is for overflow in the length field in the final value,
the algorithm doesn't handle more than 7 (or was it 6?) bytes.
Could add code to handle distinguish even bigger integers, but it didn't
seem much point. Anyway, I'll add a comment.
I think you misunderstood.
No matter what you're actually testing for, there is no way you're going to
get a TRUE result from comparing ( signed 32 bit integer > 0x7fffffff ).
If it is actually possible for ( chop * 3 > 0x7fffffff ) then this test won't
detect that fact. You need to test for
( chop > 0x7fffffff / 3 )
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/