#204 hashtable::resize bug in STLport5.2.1

[stsoe]

The function (in _hashtable.c)
template <class _Val, class _Key, class _HF,
class _Traits, class _ExK, class _EqK, class _All>
void hashtable<_Val,_Key,_HF,_Traits,_ExK,_EqK,_All>
::rehash(size_type __num_buckets_hint)

used to call _Stl_prime_type::_S_next_size(__num_buckets_hint) before doing an actual rehash. In 5.2.1 the call to S_next_size has been removed and the actual rehash in called directly with the 'hint' value supplied by the user via resize(). This leads to an exception if the user supplied the value '0' for the hint.

Thanks,
Soren Soe.

[Petr Ovtchenkov]

Looks like marginal usage. Do you have sample code that illustrate potential problem?

[stsoe]

Yes probably marginal, but I imagine this could happen after populating a hash, then shrinking it based on how many elements actually inserted. For the particular case I ran into, no elements are in the hash map at the time resize is called. Resize actually works, but the following find() causes a crash because bucket_count() is 0.

How about this small example:
#include <hash_map>
int main()
{
std::hash_map<int,int> hm;
hm.resize(0);
hm.find(0);
return 0;
}

Thanks,
Soren

[Petr Ovtchenkov]

As hm.resize(0) as hm.rehash(0) are bad usage, nonsense from algorithm point of view.

jtc1/sc22/wg21 treat issues of such kind as NAD (not a defect), but it may be issue for debug library variant. Compare with:

strlen( 0 );

or

strlen( 0x2 );