(ITS#8412) mdb_cursor_del followed by MDB_NEXT_DUP leads to unexpected behaviour

[lukaswhl@gmail.com]

Full_Name: Lukas W
Version: mdb.master 37081325f7356587c5e6ce4c1f36c3b303fa718c
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2407:7000:9a07:8600::2)


The current behaviour of MDB_NEXT_DUP after a mdb_cursor_del call is
inconsistent with those of other OPs. For instance, MDB_NEXT does not change the
cursor's position, as this was already done by mdb_cursor_del. As far as I
understand, mdb_cursor_get can be expected to behave just like usual, whether
mdb_cursor_get was preceded by a mdb_cursor_del call or not. This saves extra
checks when e.g. removing particular items in a loop based on some criterion (as
described and discussed in
http://www.openldap.org/lists/openldap-devel/201502/msg00027.html and
follow-ups).

However, this does not apply to MDB_NEXT_DUP. Consider a DB containing the
following three items:

#1: "a" --> 1
#2: "b" --> 1
#3: 2b2b" --> 2

Let's say we have a cursor that points to #1. After calling mdb_cursor_del, #1
is removed and the cursor points to #2 (though this is not documented anywhere).
We then call mdb_cursor_get with MDB_NEXT_DUP. We'd expect this call to return
MDB_NOTFOUND, as #1 was the last item with "a" as its key. This is also what it
would return if mdb_cursor_del was not called. But in fact, MDB_SUCCESS is
returned, making anyone who's unaware of this behaviour believe that there's
another item with the key "a". In my particular case, this leads to #2 being
deleted as well, even though I only expected to touch items with the key "a",
which is why I'm using MDB_NEXT_DUP instead of MDB_NEXT in the first place.
In a nutshell, MDB_NEXT_DUP does the same as MDB_NEXT after a mdb_cursor_del
call, even though one would expect it not to jump across "key boundaries".

On a side note, prior to 37081325f7356587c5e6ce4c1f36c3b303fa718c / ITS#8406
this would have resulted in an assertion failure.

You could classify this as a bug and adjust the behaviour to match MDB_NEXT's,
or you could document the behaviour of mdb_cursor_del regarding the cursor's
state. Either would be appreciated.