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

[Pádraig Brady]

On 14/01/16 17:35, Eric Blake wrote:
> 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.

Right, but we pass an int to these macros, so could they
be doing anything but referencing the relevant bits?

BTW in case WEXITSTATUS isn't always one wider than WTERMSIG,
it would be more general to do the following I think, assuming a shell
would always add just one more bit.

  const int exitmax = (WTERMSIG (~0) << 1) + 1;

Given the discussion on ksh below I suppose you could have:

  const int exitmax = (WEXITSTATUS (~0) << 1) + 1;
  verify (WTERMSIG (~0) < WEXITSTATUS (~0));

> 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).

Yes generally I was worrying about wider than 8 bit status,
which ksh is generating currently.

> 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

access denied

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

Interesting. I like that one can distinguish signals with this scheme,
while still having the full 8 bits of exit status available.
Though it's deviates from common practise and is not compat with
future wider status values.
I also see that ksh -l uses this arbitrary value % 256 processing:

  $ ksh -c 'kill -l $((2**30 + 14))'
  ALRM

For completeness I verified the exit status for signals
for various shells like:

$ for sh in bash dash zsh ksh; do
>   $sh -c "echo; echo $sh; sh -c 'kill -ALRM \$\$'; echo \$?"
> done

bash
bash: line 1: 25954 Alarm clock
142

dash
Alarm clock
142

zsh
142

ksh
ksh: 25960: Alarm call
270


I'm 50:50 on applying the limit now,
but have enough info to simplify/fix the test at least.

thanks a lot for the review/info!
Pádraig.