gh-123378: fix some corner cases of start and end values in PyUnicodeErrorObject

[picnixz]

• Issue: Incorrect handling of negative start values on PyUnicodeErrorObject #123378

[picnixz]

Thank you Victor for your review!

[vstinner]

LGTM.

@serhiy-storchaka: Do you want to double check the fix?

[encukou]

I'm a bit sad that we can't agree to fix the setters, but, if we're fixing the C getters, this is the way to go.
A few nitpicks:

[encukou]

While you're here, could you add a type check before each cast?

 assert(PyObject_TypeCheck(exc, (PyTypeObject*)&PyExc_UnicodeError)); 

Ideally, public API would raise TypeError on wrong types, but that change might be too big.

[picnixz]

Should we make a follow-up PR for adding assertions on the getters as well?

[encukou]

That would be great! Thank you for volunteering :)

[encukou]

That would be great! Thank you for volunteering :)

Oops, didn't look at the CI :/

[encukou]

Feel free to leave all the asserts to a follow-up PR.

[encukou]

Thank you!

[picnixz]

Question: should we backport this to 3.12 and 3.13? it's both a feature and a bugfix in some sense but I feel it's more a bug fix even though it could change the behaviour of some code (hopefully, not too much...). The start getter was buggy (it could return -1) but the end getter was not.

WDYT? By the way, I spotted some typos here and there. I'll correct them as part of a follow-up PR.

[encukou]

If I understand correctly, it could only return -1 with an empty string, which isn't something one would typically get encoding errors for. Also, at this level you get a wrong value rather than a crash.
I don't think it's worth backporting.

[picnixz]

it could only return -1 with an empty string

Yup. (to be clear, it's the size that is being stored in start, not the function return value which returns -1 on error and 0 on success).

In this case, subsequent calls usually lead to crashes because the C API assumes non-relative offsets in general.

I don't think it's worth backporting.

Thanks, it's essentially to know whether the patches for codecs handlers will be backported or not (without the backport of this PR, the handlers would still be broken I think).