Changes by Richard Oudkerk shibt...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
___
___
Richard Oudkerk added the comment:
pid_t is HANDLE on Windows, which is a pointer.
I think this is wrong.
The signature of getpid() is
int _getpid(void);
so pid_t should be equivalent to int.
The complication is that the return values of spawn*() etc are process handles
(cast to
STINNER Victor added the comment:
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
Richard Oudkerk added the comment:
@sbt: Would you like to have a strict separation between UNIX-like pid
(pid_t) and Windows process identifier (HANDLE)?
Yes. And would I certainly like SIZEOF_PID_T == sizeof(pid_t) ;-)
Note that _winapi takes the policy of treating HANDLE as an unsigned
Richard Oudkerk added the comment:
I see _Py_PARSE_PID already exists but no others ...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
___
Richard Oudkerk added the comment:
Attached is a patch that adds _Py_PARSE_INTPTR and _Py_PARSE_UINTPTR to
Include/longobject.h.
It also uses _Py_PARSE_INTPTR in Modules/posixmodule.c and PC/msvcrtmodule.c
and removes the definition for SIZEOF_PID.
--
Added file:
STINNER Victor added the comment:
-/* The size of `pid_t' (HANDLE). */
-#define SIZEOF_PID_T SIZEOF_VOID_P
I would prefer to have SIZEOF_PID_T defined:
#define SIZEOF_PID_T SIZEOF_INT
win32_kill() uses DWORD type, not pid_t.
Except these nits, your patch looks good and is more correct than my
Roundup Robot added the comment:
New changeset 0410bf251e10 by Richard Oudkerk in branch 'default':
Issue #17931: Resolve confusion on Windows between pids and process handles.
http://hg.python.org/cpython/rev/0410bf251e10
--
___
Python tracker
Roundup Robot added the comment:
New changeset 2298bcba6ec9 by Victor Stinner in branch 'default':
Close #17931: Fix PyLong_FromPid() on Windows 64-bit: processes are identified
http://hg.python.org/cpython/rev/2298bcba6ec9
--
nosy: +python-dev
resolution: - fixed
stage: -
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
___
___
STINNER Victor added the comment:
@Antoine (author of the commit fixing #1983): any opinion?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
___
Antoine Pitrou added the comment:
Sounds fine to me, but perhaps better test the patch before committing?
(or wait for the buildbots to crash)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
STINNER Victor added the comment:
Oh, I just noticed the following check in pyport.h:
#if SIZEOF_PID_T SIZEOF_LONG
# error Python doesn't support sizeof(pid_t) sizeof(long)
#endif
I don't understand this test, longobject.h contains:
#elif defined(SIZEOF_LONG_LONG) SIZEOF_PID_T ==
New submission from STINNER Victor:
The issue #1983 was not fixed on Windows: pid_t is HANDLE on Windows, which is
a pointer. SIZEOF_PID_T is not defined in PC/pyconfig.h and so longobject.h
takes the default implementation (use C long type):
/* Issue #1983: pid_t can be longer than a C long
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17931
___
___
Python-bugs-list
15 matches
Mail list logo
