Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Possible bugs in bit_array classes (Read 3954 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Possible bugs in bit_array classes

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.

Possible bugs in bit_array classes

Reply #1 –
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.

Possible bugs in bit_array classes

Reply #2 –
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.
Quote
Each bit_array instance has an implicit length LEN. The value of LEN cannot be queried from the bit_array but is specified by the context. Valid indexes are in the range from 0 to LEN-1 (inclusive). Using an index outside this range results in unspecified behaviour.
"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.

Possible bugs in bit_array classes

Reply #3 –
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.

Possible bugs in bit_array classes

Reply #4 –
Quote from: sun4384 on
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.
Incorrect. The maximum valid index for that class is the largest positive t_size t_ssize value (see bit_array::find()).

Quote from: sun4384 on
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?
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.

Quote from: sun4384 on
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.
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.

Quote from: sun4384 on
Beside, why are two separate bug reports merged? You may also want to address the first bug report.
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.
 

Possible bugs in bit_array classes

Reply #5 –
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.