X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=suT5
	GjQWB4dpqZYU6jPByAPZ9VtEPzKoMBPzIBSGFIgbYsjngFJWF9Bz0XzwSPpRbrrH
	/+sqM+mF59IT90+hhPrSc/qImekv6VgjBZnGRHh2VbzAnZQwZebJz/YtL8jOyppI
	02RI9FxdW+x6G0w2DEHvIy8y/+c4ExLcYh4dT5k=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; s=default; bh=HRqIkVXsKN
	PK6Kr1yoY+s1Z2kG4=; b=X60mj5t2O4lMsj+5an18KRrtBX565uLFhccAaiJsXW
	6RVvLF2AGaI2Lw3WHLnYai6UsIZyBlud9xGyzgo3Ny4nntWbyea45dZ3jgLdAobe
	mw5FLrk995Uitfws56taAXjeWixYNQHOSjDinUWnMlVe0LrJWpAK1UyCdtkQ/S1D
	M=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2
X-HELO:	mx1.redhat.com
Subject:	Re: Return codes over 1 byte
To:	cygwin AT cygwin DOT com
References:	<CAMKht8gCOXF+nObhC69_LyU+TOsbWnnK8PCt-ghgWT=40hmMaw AT mail DOT gmail DOT com>
From:	Eric Blake <eblake AT redhat DOT com>
Openpgp:	url=http://people.redhat.com/eblake/eblake.gpg
X-Enigmail-Draft-Status:	N1110
Message-ID:	<55A57E97.4050001@redhat.com>
Date:	Tue, 14 Jul 2015 15:26:47 -0600
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version:	1.0
In-Reply-To:	<CAMKht8gCOXF+nObhC69_LyU+TOsbWnnK8PCt-ghgWT=40hmMaw@mail.gmail.com>
X-IsSubscribed:	yes

--uVTi9xdg0OPGT6RSEEaewliBaHVtf7oAm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 07/09/2015 05:30 PM, Michael DePaulo wrote:
> mark06 mentioned this on IRC today and then left the channel about 1 hour=
 later:
>=20
> <mark06> has anyone ever discussed exit codes above one byte? they are
> valid on modern windows, but cygwin's bash will mess them

POSIX requires that all sizeof(int) bytes in exit() be visible to
calling apps that use waitid(); however, while Solaris has implemented
this, Linux has not (Linux intentionally truncates exit() values to 1
byte before storing it in the kernel task information, so later waitid()
has no way to reconstruct the three truncated bytes).

Since Cygwin is emulating Linux, we can also get by with truncating exit
status to one byte, although it would be nice for POSIX reasons to
eventually reach the point where waitid() can return all four bytes.


> mike AT executor ~
> $ ./return.exe
>=20
> mike AT executor ~
> $ echo $?
> 0

Most shells (bash included) are NOT using waitid() internally, but are
still sticking to the older wait() and waitpid() interfaces.  Per POSIX,
those older interfaces MUST truncate the exit status into just 8 bits,
because it is being combined with other pieces of information (hence the
WIFEXITED() macro and friends).  It is only waitid() that can return
more than 8 bits, but that in turn requires the kernel to track more
than 8 bits.  And therein lies a bootstrap problem: since Linux doesn't
yet track more than 8 bits in the kernel, most open source shell authors
have no incentive to try and use newer interfaces; but until someone
actively complains that the newer interfaces are not following POSIX,
the kernel authors have no incentive to change the kernel process
information.  And even if shell authors did switch to waitid(), current
POSIX is vague enough to state that a shell's $? will reflect only the
lower 8 bits even if the shell were wired to use waitid() internally -
that is, there is no requirement that exit(256) be mapped to a non-zero
$? rather than the normal 0 you'd get from 8-bit truncation (although
there has at least been a discussion of whether a future version of
POSIX should add extensions to the shell to expose full 32-bit exit
information [1]).

[1] http://thread.gmane.org/gmane.comp.standards.posix.austin.general/11060

--=20
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


--uVTi9xdg0OPGT6RSEEaewliBaHVtf7oAm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJVpX6XAAoJEKeha0olJ0NqbwkH/R5c28jgk0atzWQi0pcm1DfR
0MwdtfqnrKZs2vNJ0f2W2/SkD3BBKdLY8bXrmA42J/nErynmINnDxAU34X/lYerO
74zjVCSpN7dQGlb4bllG2jSQ8qQk6B9HoYPEPY+6oEk8kx5j/R3Uxv0Nbx3iLREf
eqiLePpJVi+8mtZQ37WhU5rmGpQUXVozDgT1TQkHy1d34XuJ+UitG6ECPOLLL3QF
CppZ0ZDQ21UiCoAFxKr0Pah4jnsxwtBEUnG2ymFzfehr75zps01lN5X89dQQvkG+
Tq732xPPz+9LNAxFAjbCLu+pxbyX+CUExTr/EOSdeu3VTz9qV7sFGrF4Etoa/B4=
=LI//
-----END PGP SIGNATURE-----

--uVTi9xdg0OPGT6RSEEaewliBaHVtf7oAm--

- Raw text -