-
Notifications
You must be signed in to change notification settings - Fork 26
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.