It works fine with sizes greater than 2^16.
Created attachment 241261 [details] patch
Comment on attachment 241261 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=241261&action=review > Source/WTF/wtf/BloomFilter.h:-40 > - static_assert(keyBits <= 16, "BloomFilter key size must be less than or equal to 16!"); Shouldn't we make sure it is at least <= 32 so that 1 << keyBits below doesn't overflow? I have looked carefully at the implementation but was this 16 value somehow corrected to the 16 value used in secondSlot() below?
(In reply to comment #2) > Comment on attachment 241261 [details] > patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=241261&action=review > > > Source/WTF/wtf/BloomFilter.h:-40 > > - static_assert(keyBits <= 16, "BloomFilter key size must be less than or equal to 16!"); > > Shouldn't we make sure it is at least <= 32 so that 1 << keyBits below > doesn't overflow? > > I have looked carefully at the implementation but was this 16 value somehow > corrected to the 16 value used in secondSlot() below? typo: s/corrected/connected
I just removed the assert as it is unlikely anyone would try to create anything close to a 4GB filter. I think we get sensible slot spread without any code changes. It is not entirely symmetric anymore, first slot uses the entire table while second is the lowest 2^16 slots. However there are only 16 unique bits per slot in the key anyway.
Comment on attachment 241261 [details] patch Sure, r=me
Landed - https://github.com/WebKit/WebKit/commit/c728c9b09cebb25ccf8b6d7906be1ccb334ac4e2 and didn't backed out. Marking "RESOLVED FIXED".