GeezerVison

PyUnicode_ClearFreeList was removed in Python 3.9!

Oh, these tests were written when it was here.

Maybe this error should become a ValueError, but it can be changed outside this PR, since you seem to want to backport these news tests.

I think that SystemError is better exception type here. It is a misuse of the C API, you cannot get this error from Python code.

It sounds dangerous to return a string to the "Python space" if characters are not initialized when maxchar is greated than 0x10ffff. Can you remove maxchar <= 0x10ffff condition? PyUnicode_Fill() must fail if the fill character is too big (greater than 0x10ffff).

It is a test for PyUnicode_New(), not for PyUnicode_Fill(). We should see exceptions raised by PyUnicode_New(), not PyUnicode_Fill().

It never happens, because PyUnicode_New() returns NULL if size > 0 and maxchar > 0x10ffff. If it will not return NULL, it is better to get a malformed string than get an exception raised by PyUnicode_Fill() and think that it was raised by PyUnicode_New().

For me, -1 means an error. You shouldn't have to check if an exception was raised or not. Or it should become: assert(PyErr_Occurred()).

Same remark for other test wrapper like the one for PyUnicode_Resize().

If an exception was raised, but result is not -1, then what? The code will return NULL, and we will never know that something wrong happened with PyUnicode_WriteChar().

I do not use the C assert() in these tests, because I want to make tests working even in non-debug build.

I do not use the C assert() in these tests, because I want to make tests working even in non-debug build.

C assert() are enabled on release (no-debug) builds: see the following code in Modules/_testcapi/parts.h:

// Always enable assertions
#undef NDEBUG

Many _testcapi tests are only implemented with assert().

PyMem_FREE is a deprecated alias to PyMem_Free(). I would expect the opposite change, replace PyMem_FREE with PyMem_Free :-)

Reverted. The code in my branch was written a long time ago, when PyMem_FREE and PyMem_Free were different things. I just copied it over the current code.

That's done automatically by Refleaks buildbots, no?

Maybe. But since this C API does unusual things with reference counts, it would be better to test it explicitly, if possible.

This condition looks wrong. Maybe just use else:? I don't think that Python supports other endianness. Same a few lines below.

Good catch. I though that explicit check can be better, but made an error in it.

I do not use the C assert() in these tests, because I want to make tests working even in non-debug build.

C assert() are enabled on release (no-debug) builds: see the following code in Modules/_testcapi/parts.h:

// Always enable assertions
#undef NDEBUG

Many _testcapi tests are only implemented with assert().