The issue#22110 enabled more compiler warnings. I would like to fix this one:---gcc -pthread -c -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes    -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE -oPython/thread.oPython/thread.cIn file included fromPython/thread.c:86:0:Python/thread_pthread.h: In function ‘PyThread_create_key’:Python/thread_pthread.h:611:22: attention : signed and unsigned type in conditional expression [-Wsign-compare]     return fail ? -1 : key;                      ^---Attached patch uses Py_SAFE_DOWNCAST() to explicitly downcast to int.On Linux (on my Fedora 20/amd64), pthread_key_t is defined as an unsigned int, whereas the result type of PyThread_create_key is a signed int.Nobody complained before, so I get that nobody noticed the possible overflow for a key > INT_MAX. I checked the code, we only check if PyThread_create_key() returns -1, if you reach UINT_MAX keys. UINT_MAX keys sounds insane, you probably hit another limit before.On Linux, it looks like the key is a counter and deleted values are reused:haypo@selma$ ./pythonPython 3.5.0a0 (default:a0b38f4eb79e, Aug 15 2014, 23:37:42) [GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linuxType "help", "copyright", "credits" or "license" for more information.>>> import ctypes>>> ctypes.pythonapi.PyThread_create_key()2>>> ctypes.pythonapi.PyThread_create_key()3>>> ctypes.pythonapi.PyThread_create_key()4>>> ctypes.pythonapi.PyThread_delete_key(3)0>>> ctypes.pythonapi.PyThread_create_key()3

pthread_key_create_overflow.patch: safer patch, delete the newly created key and return an error on integer overflow.

New changeset1b898b5d5ffe by Victor Stinner in branch 'default':Issue#22206: Using pthread, PyThread_create_key() now sets errno to ENOMEM andhttp://hg.python.org/cpython/rev/1b898b5d5ffe

I fixed the issue in Python 3.5, I close the issue.Even if Python 2.7 and 3.4 are also affected, I prefer to not modify them to not take the risk of introducing a regression for a corner case.