-
Notifications
You must be signed in to change notification settings - Fork 44
Description
A few thoughts on the exit code translation on Windows:
swift-subprocess/Sources/Subprocess/Platforms/Subprocess+Windows.swift
Lines 514 to 524 in 0e853a9
| var status: DWORD = 0 | |
| guard GetExitCodeProcess(execution.processInformation.hProcess, &status) else { | |
| // The child process terminated but we couldn't get its status back. | |
| // Assume generic failure. | |
| return .exited(1) | |
| } | |
| let exitCodeValue = CInt(bitPattern: .init(status)) | |
| guard exitCodeValue >= 0 else { | |
| return .unhandledException(status) | |
| } | |
| return .exited(status) |
Since Windows doesn't actually have signals, and there is only a single exit code, should we consider making the unhandledException case unavailable on Windows, and solely using exited?
(additionally, if GetExitCodeProcess fails we should probably just throw, to avoid confusing that case for an actual .exited(1))
And, given this code in SCF:
GetExitCodeProcess(process.processHandle, &dwExitCode)
if (dwExitCode & 0xF0000000) == 0x80000000 // HRESULT
|| (dwExitCode & 0xF0000000) == 0xC0000000 // NTSTATUS
|| (dwExitCode & 0xF0000000) == 0xE0000000 // NTSTATUS (Customer)
|| dwExitCode == 3 {
process._terminationStatus = Int32(dwExitCode & 0x3FFFFFFF)
process._terminationReason = .uncaughtSignal...should we consider providing some Windows-specific APIs to attempt to extract the specific HRESULT/NTSTATUS codes and their string counterparts? There's a huge namespace of Windows errors, and being able to programmatically retrieve their string values for display to a user to indicate why a process has failed could be really useful.