This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Return codes over 1 byte


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:
> 
> <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@executor ~
> $ ./return.exe
> 
> mike@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

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

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]