Guard size <= 1 in binary_fuse8_allocate as the current behaviour is unsafe.

[slimsag]

I've noticed with very small input sizes (0, 1, 10, 100) that binary_fuse8_allocate sometimes relies on some.. questionable behavior.

For example, if called with size=0, filter->Fingerprints is ultimately allocated with filter->ArrayLength = 786432 (768 KiB), which seems high given a filter size of zero.

With size=1, sizeFactor ends up being INFINITY, which makes:

xor_singleheader/include/binaryfusefilter.h

Line 153 in f190e5a

uint32_t capacity = (uint32_t)(round((double)size * sizeFactor));

result in effectively:

uint32_t capacity = (uint32_t)(round((double)0 * INFINITY)); 

https://godbolt.org/z/7vqY9ofY1

or more simply:

uint32_t capacity = (uint32_t)((double)INFINITY); 

I think this cast may be undefined behavior, as in GCC this results in -1 while in clang it results in an undefined value:
https://godbolt.org/z/daxcT7n5K

All this to say, I think very small input sizes (specifically 0, 1, 10, 100) may fail during binary_fuse8_allocate in the worst case scenario and, in the best case scenario, allocate a perhaps larger set of fingerprints than needed.

[lemire]

The case size <= 1 should definitively be guarded. It is a bug.

I do not see a problem with size = 10. Please elaborate if you still think that there is an issue.

[lemire]

cc @thomasmueller

[lemire]

@slimsag Thanks for the report. I shall be guarding these cases.

[lemire]

Fixed by commit dabe365

[slimsag]

Can confirm there is no issue with size=10. Thanks!

[lemire]

Thanks for the feedback.