[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ordered indexing for integers

Hallvard B Furuseth wrote: 
When you prepend a negative sign byte you should add 0xff (like when
sign-extending), not 0x80.


Right, good catch.

Got crashes due to a write after 'tmp', incremented size by 1.
Haven't looked at why yet, or whether that's the complete fix.


That should never happen. Do you have the backtrace from when the write occurred?

Also the utils.c code is rather larger than necessary.  So I added a few
other things while I was at it:

- add with carry can be done in a one-liner, and doesn't need any shifts.
- can use the same code to prepend positive and negative sign byte


OK.

- it makes little sense to check if there is room for the sign byte
  and then return wrong result if not.  For now I added a failure there,
  but either that error check can be removed, or there should be more
  error checks.

It should never run out of room; the binary representation will always be smaller than the buffer length. Just remove that error check.

Also the index is wrong for huge numbers.  At some point the indexing
should just give up and use max/min values, but I suppose at least
cryptograpy-sized numbers should be usefully indexed.  I.e. at least
two length bytes.

I guess that means the cutoff size should depend on the index_intlen. I don't think most people will need to handle huge values.

So here is a suggestion similar to what I wrote before, except using the
utf-8 trick to count initial bits to say how many length-bytes are
needed.  That also means only one bit is needed to say 'no length
bytes', so I reduced the indexkey size to exactly index_intlen.

In that case we must change the presence key in back-bdb. I left that unchanged since the key sizes were different so far, and ordered equality keys must be different in size from any other key types.

--
  -- 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/