GNU bug report logs - #6430
Emacs WINDOWS truncates exit status of processes to 8 bits

Previous Next

Package: emacs;

Reported by: macross84 <at> ozu.es

Date: Tue, 15 Jun 2010 17:29:01 UTC

Severity: wishlist

Tags: wontfix

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


Message #28 received at 6430 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: macross84 <at> ozu.es, 6430 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#6430: Emacs WINDOWS truncates exit status of processes to 8
 bits
Date: Wed, 15 Jun 2016 18:02:27 +0300
> From: Óscar Fuentes <ofv <at> wanadoo.es>
> Cc: Noam Postavsky <npostavs <at> users.sourceforge.net>,  macross84 <at> ozu.es,  6430 <at> debbugs.gnu.org
> Date: Wed, 15 Jun 2016 14:30:20 +0200
> 
> Eli Zaretskii <eliz <at> 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.




This bug report was last modified 4 years and 187 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.