If this change is merged in the main branch, I will write a backport to the 3.14 branch without the C23 change using typeof().

Note: Py_SETREF() and Py_XSETREF() macros also use memcpy(), but these macros are only defined if the limited C API is not used. In this case, Python.h includes <string.h> and so we are already good (no change needed). Only Py_CLEAR() of the limited C API version 3.11 and newer is affected by the issue.

The documentation also needs an update. (3.14 has the list here.)

It's somewhat hard to explain, unfortunately. Is it enough to add something vague like “<string.h> (on certain compilers)”?

I added the following sentence to the doc:

The <string.h> header is also included when using Limited API 3.11 or newer if Python is unable to get a typeof() implementation.

I'm not sure if it's worth it to document this corner case.

It looks hard to explain. Is it a good idea?

Looking more into this, I see <string.h> also defines NULL and size_t (as used in vectorcall).
These are also defined in these other headers that Python.h currently includes:

• <stdio.h> & <stdlib.h> -- not included in limited API 3.11 and below
• <wchar.h> -- which seems much less “fundamental” that string.h

Plus, I think we want to be able to use memcpy in macros/static inline functions -- as this bug shows, people tend to do that without thinking :)

I think we should go ahead and always include <string.h>.

I think we should go ahead and always include <string.h>.

Ok, let's do that.