[email protected] wrote: > On 07/12/15 10:14, [email protected] 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
