Well, caches to speed up other things have been mooted from time to
time, but POSIX's ndbm.h isn't up to supporting them as a strictly
POSIX-conforming program is crippled by how it can use a ndbm.h
key-value store.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dbm_store.html
explains the limitations, e.g. all keys that hash the same, and their
values, have to fit in a block, the hash can't be obtained, the error
when the block's full is no different to an error for another reason.
Right, I had noticed that when I looked at it during this conversation,
and I hadn't quite appreciated how limiting the POSIX dbm API is when
this came up earlier.
By all means make ndbm.h optional, it's pretty useless for a conforming
program, but at the moment it doesn't seem to be causing ./configure
trouble to porters.
Well, look through the archives ... you'll find a number of people for
whom it causes problems (a lot of those problems seem to stem from some
Linux distributions having separate "devel" packages which contain the
bits you need to compile a program, and I guess the exact package you
needed is never obvious).
SQLite would be another way, I think Lyndon used to suggest it? But
it's a lot bigger, not POSIX, and we'd be writing SQL.
Urrrk. No desire to do that; I've written Berkeley DB stuff for work
and I understand it's quirks, but again I don't really WANT to use
it for this tiny corner case.
--Ken