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

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  macross84@ozu.es,  6430@debbugs.gnu.org
> Date: Wed, 15 Jun 2016 14:30:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Not really sure what this reformatting is about, but I think the point
> >> is that the original value does not return to lisp.
> >
> > Why is that a problem?
> 
> Because Emacs is reporting something false?

Only if the value is greater than 255.

> > The important information that I thought this was about is in the
> > upper 4 bits of the status, and it doesn't get lost -- it's passed
> > back to Emacs as the signal (if any) that caused the subprocess to
> > exit.
> >
> > If there are any important use cases with programs that return status
> > above 255, we can easily change the definition of WEXITSTATUS for
> > Windows.  But I have yet to see a real-life example of such a program,
> > or any complaint about the current WEXITSTATUS definition in Emacs.
> 
> You are fortunate enough to live in a world of applications ported from
> *nix :-) (and so do I, for the most part.)

Emacs does more than that.  To see that, interrupt a console program
with Ctrl-C, and then display its exit status using %ERRORLEVEL%.
Then do the same inside Emacs and compare the results.  That's what I
thought the OP was alluding to.

> When a Windows application calls an API that fails and the application
> has no method for recovering from the error, it is customary to exit
> with the error code of the API (usually obtained with GetLastError).

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.