STINNER Victor <[email protected]> added the comment:
Eryk:
> FWIW, I wouldn't recommend relying on os.waitpid to get the correct process
> exit status in Windows. Status codes are 32 bits and generally all bits are
> required. os.waitpid left shifts the exit status by 8 bits in a dubious
> attempt to return a result that's "more like the POSIX waitpid". In
> particular, a program may exit abnormally with an NTSTATUS [1] or HRESULT [2]
> code such as STATUS_DLL_NOT_FOUND (0xC000_0135) or STATUS_CONTROL_C_EXIT
> (0xC000_013A).
os.waitpid() calls _cwait() on Windows and uses "status << 8".
The result is a Python object. IMHO it's ok if the shifted result ("status") is
larger than 32 bits. But I'm not sure that the current os.waitpid()
implementation handles integer overflow correctly...
When I look at GetExitCodeProcess() documentation, I don't see any distinction
between "normal exit" and a program terminated by TerminateProcess(). The only
different is the actual exit code:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getexitcodeprocess
Do you suggest that os.waitstatus_to_exitcode() result should be negative if a
process was terminated by TerminateProcess()?
--
My PR 19201 is based on the current Python implementation and assumptions used
in the current code. But I don't think that what you wrote can be an API issue.
It's more the opposite, if tomorrow we want to encode the status of a
terminated process differently, it will be easier if
os.waitstatus_to_exitcode() is available, no?
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue40094>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
