Try the following code. The last should return 1, but returns 0 actually.

console::formatter() << bit_array_one(10).calc_count(true,0,10);
console::formatter() << bit_array_one(10).calc_count(true,0,20);
console::formatter() << bit_array_one(10).calc_count(true,0,infinite);

The bit pattern of infinite is equal to negative one. It's ok in unsigned world, but causes trouble if used in signed world. In the body of calc_count, find is called, whose last parameter is declared to be signed. There happens treating infinite as minus one, causing the function fail in such a case.

In other bit_array_xxxx classes, the get method is written not to access out-of-index bits. However in bit_array_order_changed, it's not, and may allow accessing invalid memory location.

The only bug I can see here is that the bit_array class is lacking some documentation that describes its intended and actual use in foobar2000.
"Unspecified behaviour" may include wrong results, segmentation faults, or whatever else you (dis)like.

"By the context" usually means that a callback that is passed a reference to a bit_array is also passed its length.

The fact that some bit_array implementations support an arbitrary length is merely a convenience.

The idea of finite length bit_array is problematic, because:

1. some bit_arrays are inherently infinite length, like bit_array_true for example. Valid index range is all non-negative integer.

2. some bit_arrays are defined using other bit_arrays, like bit_array_and. You have to define the behavior of merging two bit_arrays of different lengths. Moreover, what to do with bit_array_not?

3. there are many SDK methods that takes bit_array objects as parameter, and it's not possible to pass "the context" together without changing the method signature.

Beside, why are two separate bug reports merged? You may also want to address the first bug report.

Incorrect. The maximum valid index for that class is the largest positive t_size t_ssize value (see bit_array::find()).

The bit_array classes that perform logical operations on other bit_arrays are examples for bit_array implementation that support arbitrary length which I mentioned before. Naturally, their actual valid index range is the intersection of the valid index ranges of their arguments.

When you use a bit_array to select a subset of a list, the required length of the bit_array is the length of the list, unless the method in question allows to specify a range, in which case it may be less.

They really are the same thing. See my answer to 1. above, infinite is not a valid index for bit_array_one.

Edit: Fixed typo.

Please state such intentions somewhere in the SDK. My own opinion, but I still think if you wanted bit_arrays to have finite length, it should be possible to obtain the length in a fashion like bit_array::get_length(), rather than from the context. Or, even the infinite length bit_arrays might be a better choice because other than bit_array_order_changed, bit_arrays are implemented perfectly for infinite length.