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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 15 Jun 2016 20:32:43 +0300

> 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.

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).
Feel free to submit patches to that effect if you like.