bugfix:deserialize:cotainers max len should be 2^16+1

[detailyang]

Hello.

RoaringBitmap's cotainers max len should be u32::max_value() u16::max_value() + 1 rather then u16 in deserialize.

[Kerollmops]

Hey,

Have you checked that in the RoaringBitmap format specification?
Because IIRC there cannot be more than 2^16 containers where each container contains from 0 to 2^16 numbers.

But maybe you are right :)

[lemire]

The actual cardinality is between 1 and 2^16, and 2^16 will overflow a 16-bit word. The workaround is to represent the cardinality as a number between 0 and 2^16-1 with the convention that empty containers are prohibited: this works during serialization and deserialization because we never store or load an empty container.

[detailyang]

@lemire @Kerollmops

Sorry. I just recently read the spec https://github.com/RoaringBitmap/RoaringFormatSpec, The container max length should be 2^16 rather than 2 ^ 32 or 2^16-1.

Checkout the test case named test_bitmap_high16bits :)

Many thanks!

[detailyang]

@Kerollmops Can you have look at this? I'm sure the u16::max_value is not right :) See the test case named test_bitmap_high16bits

Many thanks

[Kerollmops]

Yeah, I will take a look at that, thank you for your time :)

bors try

[Kerollmops]

Indeed you have found a bug in the deserialization process, thank you very much! Could you just fix the fmt issue that I suggested to you, please?

To resume your test, you insert big numbers until 2^32, the maximum possible value, these big numbers will force the RoaringBitmap to create a container for each one of those (?), resulting in 2^16 containers. Finally you check that you are able to deserialize them.

To fix this bug, you have modified the condition that was checking for a correct amount of containers to be under 2^16 instead of under 2^16+1.

[Kerollmops]

Thank you!

bors r+

[bors]

Build failed:

• ci (stable)

[Kerollmops]

bors r+

[bors]

Build succeeded:

• ci (stable)

[bors]

try

Timed out.