[thrust] counting_iterator::distance_to ignores the stride
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
### Is this a duplicate?
- [x] I did not find any issue that matches what I described.
### What happens?
`thrust::counting_iterator` supports an optional stride (`make_counting_iterator(0, 2)`), added in #4014. `advance`/`increment`/`decrement` scale every move by the stride, but the random-access `distance_to` implementation returns the raw difference of the underlying counters without dividing by the stride.
So for `first = make_counting_iterator(0, 2)` and `last = make_counting_iterator(10, 2)`:
```cpp
last - first // returns 10, should be 5
first + (last - first) == last // false: advance multiplies the raw distance by the stride again
```
Algorithms size their work from the distance, so e.g. `thrust::copy(first, last, out.begin())` reads past the end of the logical range and overruns the destination when the output is sized from the element count.
The same gap does not exist in `thrust::strided_iterator` or in `cuda::strided_iterator`, which both divide by the stride in `distance_to`.
### How do we reproduce?
```cpp
auto first = thrust::make_counting_iterator(0, 2);
auto last = thrust::make_counting_iterator(10, 2);
assert(last - first == 5); // fires: reports 10
```
Introduced with the stride support itself (#4014); the arithmetic paths were never updated.
Contributor guide
Assessment
This issue has not been assessed yet.