Re: [platform-testers] new snapshot available: coreutils-8.24.150-4ab87

[Eric Blake]

On 01/14/2016 08:16 AM, Pádraig Brady wrote:

>  
> +  kill and timeout now only convert exit status values that could be used
> +  to represent a signal.  For example `kill -l $((2**30+1))` now reports
> +  an invalid signal representation, when previously it returned "HUP".
> +
>    mv no longer causes data loss due to removing a source directory specified
>    multiple times, when that directory is also specified as the destination.
>    [bug introduced in coreutils-8.24]
> diff --git a/src/operand2sig.c b/src/operand2sig.c
> index a9fede5..15dbec7 100644
> --- a/src/operand2sig.c
> +++ b/src/operand2sig.c
> @@ -40,9 +40,10 @@ operand2sig (char const *operand, char *signame)
>    if (ISDIGIT (*operand))
>      {
>        char *endp;
> +      const int exitmax = WEXITSTATUS (~0);

I think this may be undefined behavior to call WEXITSTATUS on ~0;
WEXITSTATUS() is only defined on 16-bit status values returned through
the wait() family, and even then only if WIFEXITED() is true.

Furthermore, we KNOW that the maximum exit value through the wait()
family is limited to 8 bits, except for waitid() on kernels that support
32-bit exit status (Solaris and some BSD do, but Linux still doesn't).

Today's Austin Group meeting was all about whether shells should start
using waitid() to provide a (new) way to get at full 32-bit exit status
(assuming underlying kernels are fixed to provide it in the first
place), while still keeping $? as the mod256 value for back-compat:
http://posix.rhansen.org:9001/p/2016-01-14

And then there's ksh, which intentionally sets $? to 256+n rather than
128+n for representing signals, so we absolutely want 'kill -l 258' to
report SIGHUP and not that it is out of range fore being larger than 255.

So overall, I'm not sure this patch is right.

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

signature.asc
Description: OpenPGP digital signature