h.b.furuseth@usit.uio.no wrote:
On 07/12/15 10:14, h.b.furuseth@usit.uio.no wrote:
Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does not warn against 0 items. I suggest supporting 0 items, it is a commonly supported convenience elsewhere (e.g. memcpy).
I.e. supporting it as a no-op. But on second thought I think that's misleading and EINVAL is better: If the key doesn't exist, this is an attempt to create a key with no data. Unsupported. Bryan Matsuo just posted a test case to openldap-technical.
EINVAL makes sense here.
datacount > UINT_MAX is truncated to unsigned int: data[1].mv_size = 0x100000002 puts 2 items.
datacount * datasize can exceed UINT_MAX, which mdb_page_spill() truncates to unsigned int. Such a massive put() will likely fail anyway, but it should at least try to spill properly first.
We should probably check if mv_size is greater than UINT_MAX and return EINVAL. (Or ERANGE.)
Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it.
Because get only works with a cursor.