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.
This commit is contained in:
Tim Peters 2001-08-29 21:37:10 +00:00
parent 1936745668
commit 79248aa1e4
6 changed files with 22 additions and 17 deletions

View file

@ -152,7 +152,7 @@ static void PyThread__init_thread(void)
*/
int PyThread_start_new_thread(void (*func)(void *), void *arg)
{
uintptr_t rv;
unsigned long rv;
int success = 0;
dprintf(("%ld: PyThread_start_new_thread called\n", PyThread_get_thread_ident()));
@ -161,7 +161,7 @@ int PyThread_start_new_thread(void (*func)(void *), void *arg)
rv = _beginthread(func, 0, arg); /* use default stack size */
if (rv != -1) {
if (rv != (unsigned long)-1) {
success = 1;
dprintf(("%ld: PyThread_start_new_thread succeeded: %p\n", PyThread_get_thread_ident(), rv));
}