This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients eryksun, vstinner
Date 2020-03-31.17:30:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:

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?
Date User Action Args
2020-03-31 17:30:04vstinnersetrecipients: + vstinner, eryksun
2020-03-31 17:30:04vstinnersetmessageid: <>
2020-03-31 17:30:04vstinnerlinkissue40094 messages
2020-03-31 17:30:04vstinnercreate