GeezerVison

I'm not sure we care, but we might -- am I right that this writes pickles that can't be read by 3.11 or before?

No, absolutely no. I would never propose such change.

Internals will be different, but the unpickled iterator wil produce the same values.

This is a little scary -- if the new length is set but computing the new start fails, and the original iterator is still accessible, it will be truncated at the end rather than at the start. Let's update both fields after all errors have been checked.

Ditto in next().

Good point. Although __setstate__ is only supposed to be called for just created object when unpickle or make a deep copy, so there are no references to that iterator yet.

But there were other issue here. state could be a borrowed reference to r->len. It is used in two places: with PyNumber_Subtract() and with PyNumber_Multiply(). The second time it is used after setting the new r->state, when it can refer to a freed memory.

next() does not have such issue.

Seems that it never happens in normal code. You have to call __setstate__() manually with the out-of-range value.

I don't see a scenario where we can't just use

Py_SETREF(r->len, new_len);
Py_SETREF(r->start, new_start);

(which would be a little easier to follow).

Both new_len and new_start are definitely new references we own, so even if state was a borrowed reference to r->len everything would be all right.

I'll leave it up to you though.

Py_SETREF can only help when you assign a single object attribute, or if the attributes are independent. Two sequential Py_SETREFs can be a sign of a bug.

We do not check the type of state. It can be an arbitrary Python object with methods __lt__, __gt__, __mul__ and __rsub__. Therefore we do not control the types of new_len and new_start. Therefore we do not control the types of r->len and r->start. They can have __del__ methods which release the GIL after assignment in Py_SETREF. When the GIL is released, the iterator object can be used in other thread when it is in inconsistent state -- new r->len and old r->start.

It never occurs in normal code (state is always an exact int), but if you try hard, you perhaps can reproduce this.

Aha, that's a scenario I hadn't considered. Maybe the next time I am asked in some kind of Q&A or interview "do you have any regrets" I should mention __del__ methods.