>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.
>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.



Reply via email to