SF bug [#456252] Python should never stomp on [u]intptr_t.

pyport.h:  typedef a new Py_intptr_t type.
    DELICATE ASSUMPTION:  That HAVE_UINTPTR_T implies intptr_t is
    available as well as uintptr_t.  If that turns out not to be
    true, things must get uglier (C99 wants both, so I think it's
    an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread:  MS _beginthread is documented
    as returning unsigned long; no idea why uintptr_t was being used.
Others:  Always use Py_[u]intptr_t, never [u]intptr_t directly.

1 files changed, 1 insertions, 1 deletions

diff --git a/PC/msvcrtmodule.c b/PC/msvcrtmodule.c
index 2714458..4584370 100755
--- a/PC/msvcrtmodule.c
+++ b/PC/msvcrtmodule.c
@@ -98,7 +98,7 @@ static PyObject *
 msvcrt_get_osfhandle(PyObject *self, PyObject *args)
 {
 	int fd;
-	intptr_t handle;
+	Py_intptr_t handle;
 
 	if (!PyArg_ParseTuple(args,"i:get_osfhandle", &fd))
 		return NULL;