We should import a c implementation of bloom filter and get rid of dbm.

On February 2, 2018 6:12:20 PM UTC, Ken Hornstein <k...@pobox.com> wrote:
>>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
>>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.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to