fleur

> There is also strange code like this loop https://github.com/hashlookup/fleur/blob/4ee2644a850381d928a... that jumped into my eye. The line below that is worse: strncpy(bloom_path , argv[optind], 128); If you pass something >= 128 chars then bloom_path won't be null terminated. In general strncpy should never be used for copying strings. For expansion on that: https://ramblings.implicit.net/c/2014/05/02/c-functions-that...

Sorry if this is a bit negative but from a cursory look I wouldn't use this. An efficient Bloom Filter should only allocate on heap exactly once: when allocating the initial bitmap. This implementation seems to be not very efficient as it allocates even during a simple query. The usage of `static` variables makes the BloomFilter code unnecessarily dangerous to use when multiple threads are used even if every thread just wants to allocate and use totally separate bloom filters. Actually it could even cause issues with two bloom filters created after each other since even `Initialize` just returns a pointer to a single static `BloomFilter` :o I can't come up with a reason why you'd consider making anything in there `static`. There is also strange code like this loop https://github.com/hashlookup/fleur/blob/4ee2644a850381d928a... that jumped