bug#6430: Emacs WINDOWS truncates exit status of processes to 8 bits

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Cc: npostavs@users.sourceforge.net,  macross84@ozu.es,  6430@debbugs.gnu.org
>> Date: Wed, 15 Jun 2016 19:14:25 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> > GetLastError has nothing to do with this, because it's not an API that
>> >> > fails, it's a program that exits with some arbitrary exit code.
>> >> 
>> >> if( ! CreateProcess(....) ) {
>> >>   DWORD ec = GetLastError();
>> >>   // do some cleanup
>> >>   ExitProcess(ec);
>> >> }
>> >
>> > That's not how Emacs does that, see waitpid and its callers.
>> 
>> Once again, we are miscommunicating. AFAIU this is about Emacs calling a
>> process foo which returns an exit code larger than 255, but Emacs only
>> reports the lower 8 bits to the Elisp function that started the process.
>> 
>> In w32proc.c waitpid:
>> 
>>   if (!GetExitCodeProcess (wait_hnd[active], &retval))
>>   ...
>>   retval <<= 8;
>> 
>> Windows applications make use of the full 32 bits of the return code.
>> With Emacs it is impossible to know those larger-than-255 exit codes.
>
> But not because of the code you cite: the 8-bit left shift just means
> we can report 24 bits out of 32.  And all of that is completely
> unrelated to GetLastError, because errors in starting the subprocess
> are not reported via waitpid.

GetLastError on my example was on the *called* process, not on Emacs.

> Once again, if this is important (I don't think so), we can redefine
> WEXITSTATUS etc. macros to keep all the 32 bits of the exit status
> (actually, the top 2 bits are reserved, so only 30 bits can be used).

When using --with-wide-int (or when running on Windows 64bits) we have
the full 32 bits, right?