NVIDIA / NVIDIA/cccl

[thrust] counting_iterator::distance_to ignores the stride

Open
#10,965 1 comment 0 reactions 1 assignee Claimed by @griwes View on GitHub
needs triage
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.