Bug in PyObject_CopyData leads to incorrect data copying order

[buxingtan]

Bug report

Bug description:

version: python 3.14.2

/* Objects/abstract.c, function PyObject_CopyData, lines 727~732 */
    while (elements--) {
        _Py_add_one_to_index_C(view_src.ndim, indices, view_src.shape); /* WRONG: increment before copy */
        dptr = PyBuffer_GetPointer(&view_dest, indices);
        sptr = PyBuffer_GetPointer(&view_src, indices);
        memcpy(dptr, sptr, view_src.itemsize);
    }

maybe can change to

    while (elements--) {
        dptr = PyBuffer_GetPointer(&view_dest, indices);
        sptr = PyBuffer_GetPointer(&view_src, indices);
        memcpy(dptr, sptr, view_src.itemsize);
        _Py_add_one_to_index_C(view_src.ndim, indices, view_src.shape);
    }

I don't know which other versions, besides version 3.14.2, are involved with this code.

CPython versions tested on:

3.14

Operating systems tested on:

Windows

[picnixz]

Please show us a reproducible issue with clear expectations.

[a12k]

Guessing this is an off by one error given _Py_add_one_to_index_C is called before the first memcpy. Would love to see a repro, which should be straightforward to produce @buxingtan.

[buxingtan]

Please show us a reproducible issue with clear expectations.

Sorry, after further debugging and analysis, I've realized that the _Py_add_one_to_index_C function eventually cycles the index back to the start position, ensuring that all data is copied completely. So this is not actually a bug - it's just an unconventional copy order.

[buxingtan]

Guessing this is an off by one error given _Py_add_one_to_index_C is called before the first memcpy. Would love to see a repro, which should be straightforward to produce @buxingtan.

copy order is 1->2->...->N->0, so it can ensure copy completely.

[picnixz]

Closing as not a bug then. One reason why we cycle back is perhaps because of overlapped or other intricate stuff. Or because of some internal pointer arithmetic.