C ++ Unordered_set函数中的溢出

Question

TBH, Im surprised Im asking this question but looking at this code

template <class _Tp, class _Hash, class _Equal, class _Alloc>
void
__hash_table<_Tp, _Hash, _Equal, _Alloc>::rehash(size_type __n)
{
    if (__n == 1)
        __n = 2;
    else if (__n & (__n - 1)) // >>>>>>LINE IN QUESTION<<<<<<<<<<<
        __n = __next_prime(__n);
    size_type __bc = bucket_count();
    if (__n > __bc)
        __rehash(__n);
    else if (__n < __bc)
    {
        __n = _VSTD::max<size_type>
              (
                  __n,
                  __is_hash_power2(__bc) ? __next_hash_pow2(size_t(ceil(float(size()) / max_load_factor()))) :
                                           __next_prime(size_t(ceil(float(size()) / max_load_factor())))
              );
        if (__n < __bc)
            __rehash(__n);
    }
}

On that line above, should __n be allowed to be zero, that - 1 next to it leads to an integer overflow that a debugger (in my case XCode) catches and complains about. Now, my understanding here is that the & operation on that line may make the line as a whole still relevant for the hashing process. But what have others done to work around this?? Silence the debugger? The function call that did this was another std library call:

template <class _Value, class _Hash, class _Pred, class _Alloc> 
     unordered_set<_Value, _Hash, _Pred, _Alloc>::unordered_set(const unordered_set& __u)
     : __table_(__u.__table_){
        #if _LIBCPP_DEBUG_LEVEL >= 2
           __get_db()->__insert_c(this);
        #endif
           __table_.rehash(__u.bucket_count()); // >>FUNCTION CALL<<<<
           insert(__u.begin(), __u.end());
      }

Here the __u.bucket_count() returns zero and thus the behaviour in question occurs. The error or sanitizer warning I received by the Undefined behaviour sanitizer in XCode was Unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long'

Answer 1

It seems a bug report was created about it and one of the developers answered it here https://bugs.llvm.org/show_bug.cgi?id=38606 It seems the operation performs a check to see if it's a power of 2. This this code is very intentional.

According to this ticket here, https://bugs.llvm.org/show_bug.cgi?id=25706 , it seems they are going through and silencing all such interesting occurrences in the standard library.

So that's my answer I guess. Either wait for them to silence it or I can silence it myself if not ignore it.