This way of writing decrementing unsigned loops is also usually generating better assembly code than the “use i-1 inside loop” method or the “compare to SIZE_MAX” method.

From: https://en.cppreference.com/w/cpp/language/operator_arithmetic#Conversions
"Unsigned integer arithmetic is always performed modulo 2n
where n is the number of bits in that particular integer. E.g. for unsigned int, adding one to UINT_MAX gives ​0​, and subtracting one from ​0​ gives UINT_MAX.

When signed integer arithmetic operation overflows (the result does not fit in the result type), the behavior is undefined:"

Therefore everything here is perfectly defined (so maybe you can change the title). It is just a user introduced bug. Still I am always happy to read your blog and discuss coding. Keep up the good work!

for (unsigned int bitIndex = bits.size() - 1; bitIndex >= 0; --bitIndex)

Then this is a well known c/c++ idiom. The type of bitindex is correct as an index shouldn’t be negative – but as is detailed above, in this loop implementation bitindex can go negative which means a large positive number as an unsigned number can’t be negative.

The ‘standard’ solution to this is to rewrite the loop (as mentioned by Gerald) so that bitindex can never be negative – not to make bitindex an int.

for (auto bitIndex = bits.size(); bitIndex > 0; --bitIndex)
{
    auto& bit = bits[bitIndex - 1];

    flip(bit);

            if (bit == true)
        break;
}

As has been pointed out, this has absolutely nothing to do with auto which is blameless in this matter.