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

From: Óscar Fuentes <[email-masked]>
Date: Wed, 15 Jun 2016 19:36:14 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Óscar Fuentes <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Wed, 15 Jun 2016 19:14:25 +0200
>> 
>> Eli Zaretskii <[email-masked]> 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?