> The complication is that the return values of spawn*() etc are process handles (cast to intptr_t), not pids:

I opened this issue because of a compiler warning in os.waitpid(). On Windows, the C function _cwait() is used and it expects a intptr_t ("handle to the process to wait on") and returns a intptr_t ("returns the handle of the specified process").... But os.waitpid() uses PyLong_FromPid() to convert the C intptr_t to a Python int, which may loose most significant bits (sizeof(void*) > sizeof(int) on Windows x64).

I see that PC/pyconfig.h defines "typedef int pid_t;". Because intptr_t is bigger than int, using intptr_t is compatible with pid_t, at least for PyLong_FromPid(). It may be a problem in the other direction: PyLong_AsPid().

Python code using Windows HANDLE is not consistent. Sometimes, intptr_t is used, sometimes long is used. Examples:

- msvcrt.open_osfhandle() parses an handle with "l" (long) format, whereas it should uses a wider type.

- msvcrt.get_osfhandle() uses PyLong_FromVoidPtr() to convert an C Py_intptr_t to a Python int, with the following comment:

    /* technically 'handle' is not a pointer, but a integer as
       large as a pointer, Python's *VoidPtr interface is the
       most appropriate here */

--

@sbt: Would you like to have a strict separation between UNIX-like pid (pid_t) and Windows process identifier (HANDLE)? 

Can we consider that HANDLE is a pointer? Or can we consider that HANDLE is intptr_t or intmax_t? See the issue #17870 which proposes an API to handle intmax_t.

If we want to be more explicit, we should add functions to handle the C HANDLE type. Example:

- PyLong_FromHandle(): C HANDLE to Python int
- PyLong_AsHandle(): Python int to C HANDLE
- "P" format (or another letter): PyArg_Parse*() format