I'm not really sure what "long" has to do with it...

The problem is that the PyThread API uses ints to represent TLS keys, and has for about as long as it's existed (maybe what you meant by "long").  But when support for native TLS was added (#9786 for pthread, sometime earlier for Windows) , the faulty assumption as made in several places that this API (i.e. the type of key is "int") should always map perfectly onto native APIs, and it doesn't.

There are several places for example where an int key is passed to pthread_getspecific and pthread_setspecific (http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_getspecific.html).  On Linux the compiler happens to allow this because pthread_key_t is defined as "unsigned int"  So yeah there's an implicit cast, but since it counts up from zero it usually works.  Likewise TlsAlloc on Windows expects the key to be a DWORD but the compiler will accept an int.

This is really an unsafe assumption though, especially when PyThread_create_key casts the key to an int, and later reuses the (possibly not safely cast) key with PyThread_delete_key/get_key_value/set_key_value).  This was brought up at the time, where MvL wrote:

> In principle, this is really difficult to get right. AFAICT,
pthread_key_t doesn't even have to be an integral type, and even
if it is, it may well become -1. However, we can probably worry
about this when a system comes along where this implementation
breaks.

One possible workaround without changing the existing API would be this:  Each native support wrapper should also provide a *safe* mapping between its native key types and ints, to support the PyThread API.

For example, the pthread interface could maintain a linked list or an even an array of pthread_key_t pointers, and use the int "key" as the index into that list.  If I understand correctly this should be basically harmless since the same key (and hence key -> native-key mapping) can be shared across threads.