The index(int) of entries(queue.BytesQueue) overflows the hashmap's uint32 value about bigcache HOT 4 CLOSED

Sure, then I can make a patch and test it.

from bigcache.

Looks like we should use uint64 in

from bigcache.

Looks like we should use uint64 in

bigcache/shard.go

Line 19 in 982ec3b

hashmap map[uint64]uint32

I think it will be backward compatible change. Would you like to contribute a patch with a test for this case?

I was thinking the same change. However, it could potentially increase the total space of the BigCache in the case if people use it to store a huge number of small entries. The size of entries Queue won't change, but the size of map keys will be doubled. Will this be a concern for the original BigCache design?

from bigcache.

That's true. The solution could be to change map type when we hit given threshold.
I'm wondering if this issue is the root cause of #290
Anyway, although change from 32 to 64 bits could double memory overhead I believe this footprint should be small enough that nobody will notice.

from bigcache.