Hallvard Breien Furuseth wrote: > test001 still crashes if you insert > assert(a->mv_size == sizeof(int) && b->mv_size == sizeof(int)); > in mdb_cmp_int(). > Using RE24 commit 98f70f1841f85d93 "ITS#8120 Move final...".
Not happening here, all tests pass with asserts enabled. > I don't see "same size" in the INTEGERDUP doc, it's looser > than for INTEGERKEY integers. Or have I gone blind again? > Anyway, it would be clearer to cut some doc and say data > behave like INTEGERKEY keys. Ignoring that, though: > > Looking yet again at the doc, mdb_dbi_open():INTEGERKEY > says "typically" sizeof(int/size_t), I can't see it > requires these sizes. Maybe you copied that from a > suggestion from me back when I asked for clarifications. Probably. The point was to show the expected sizes without enumerating every possible C integer type that would work - e.g. unsigned int, unsigned long, off_t, pid_t, whatever. At some point you have to say "don't be an idiot." > "keys must all be of the same size" in the doc is unclear. > I gather it should be "... in the DB's lifetime". But it > can be read as "...at a given time": Write size_t-sized > integers, empty the DB, then write int-sized integers. > That does not work, since me_dbxs[].md_dcmp is updated. Don't be an idiot. If no time is stated, then it's For All Time. Anything not called out specifically is, by definition, non-specific. > "mc->mc_dbx->md_dcmp = mdb_cmp_clong;" looks wrong. > That updates env->me_dbxs[], I believe. But: > > If we mdb_txn_abort(), the txn has not been a no-op: > It will require next txn and even existing txns to use > size_t-sized INTEGERDUP data. Good point. I've committed a revised patch to leave the mc_dbx pointer alone. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
