Re: (ITS#8117) Bugs related to key-size in lmdb and backend

[hyc@symas.com]

leo@yuriev.ru wrote:
> Full_Name: Leo Yuriev
> Version: 2.4-HEAD
> OS: RHEL7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (31.130.36.33)
>
>
> 1) LMDB: On 64-bit systems, in some cases mdb_cmp_int() could be called instead
> of mdb_cmp_long(), when key.mv_size == 8.
> To reproduce this is enough add an assertion-check for key.size == sizeof(int)
> into mdb_cmp_int().A%A

You need to provide more details than this. mdb_cmp_int() isn't even 
used on regular databases, only on DUPSORT databases. Provide actual 
code reproducing the issue.

> 2) LMDB: There is no any checking for invalid key-size for MDB_INTEGERKEY and
> MDB_INTEGERDUP. Therefore, for example, mdb_cursor_put() accepts a key.size == 1
> and so forth.

Not a bug, MDB_INTEGERKEY is documented to only be used with word-sized 
keys.

> 3) lmdb-backend: AttributeDescription->ad_type->sat_equality->smr_indexer()
> could generate a 5-byte sized ks.s. I can just imagine what this can create a
> many problems. For instance, when I adds the control for key size, it breaks
> test017-syncreplication-refresh. But I am not tested more.

Not a bug, indexer keys are padded to 8 bytes.

> P.S.
> It is a one more nice rebus from Howard ;)

Thanks for the irrelevant editorials. It might even be amusing if they 
were true, but mostly they just demonstrate your inexperience.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/