Terminal exit codes are unsigned but should be signed.

[zevisert]

• VSCode Version: 1.23.0
• OS Version: Win 10 Pro (Insider): 17666.rs_prerelease.180504-1501

Steps to Reproduce:

1. Attempt to use WSL as the integrated terminal on a machine where WSL is not installed. Set "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\wsl.exe" in user settings.
2. Open the integrated terminal.

Doesn't have to be WSL. This should occur on any process that returns -1. Also tested using the following C program executed using terminal.integrated.shellArgs.windows.

int main(void)
    return -1;
}

Does this issue occur when all extensions are disabled?: Yes

[jerch]

From Win API:

typedef unsigned long DWORD;
...
BOOL WINAPI GetExitCodeProcess(
  _In_  HANDLE  hProcess,
  _Out_ LPDWORD lpExitCode
);

Nope, it should not be signed. Also for POSIX systems it is defined as unsigned (a byte only there). Note that in the old C standard main always had to return an int, but the OSes behind do not have to support this. (After returning from main the kernel steps in to do some process cleanup stuff and you are leaving C programming semantics anyway.)

[zevisert]

Hmm I always thought -1 was a valid return code. It's actually what I thought EXIT_FAILURE is defined as in C. I guess it's WSL that shouldn't be using signed numbers then. Thanks.

[jerch]

@zevisert
The exit macros can have different values yes, but will most likely follow the OS standards to return something meaningful (also see https://en.wikipedia.org/wiki/Exit_status). For example on x86 even on POSIX the return value is internally 32bit in eax (due to the calling convention), but gets stripped to the lower 8 bits later to follow the spec. Not sure what the WSL subsystem does here, in theory they could allow -1 as EXIT_FAILURE and would have patched the define accordingly.
Therefore it is never a good idea to hardcode those values as they can have different "real values" (same goes for NULL in C, although the newer C99 standard explicitly declares 0 == NULL now, it was not safe to assume this before).