On 14/01/16 18:33, Pádraig Brady wrote:
> On 14/01/16 17:35, Eric Blake wrote:
>> 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
> 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!
Patch is attached, fixing/simplifying the test,
and adding lots of info about exit status limits.
thanks again,
Pádraig.
>From f385162d98ce5201740bef0072978e1c741e6d09 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com>
Date: Thu, 14 Jan 2016 14:21:53 +0000
Subject: [PATCH] tests: simplify invalid signal determination for kill -l
* src/operand2sig.c (operand2sig): Add a detailed comment explaining
why we validate even very large shell exit status values.
* tests/misc/kill.sh: Add a test case for the ksh scheme.
Simplify the INVALID signal number determination which also avoids
a false failure on systems like FreeBSD 10 with incomplete
signal list (caused by inaccurate NSIG).
---
src/operand2sig.c | 11 +++++++++++
tests/misc/kill.sh | 11 ++++++++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/operand2sig.c b/src/operand2sig.c
index a9fede5..44f390b 100644
--- a/src/operand2sig.c
+++ b/src/operand2sig.c
@@ -39,6 +39,17 @@ operand2sig (char const *operand, char *signame)
if (ISDIGIT (*operand))
{
+ /* Note we don't put a limit on the maximum value passed,
+ because we're checking shell $? values here, and ksh for
+ example will add 256 to the signal value, thus being wider
+ than the number of WEXITSTATUS bits.
+ We could validate that passed exit status values
+ were not above say ((WEXITSTATUS (~0) << 1) + 1), which would cater
+ for the ksh case, but some shells may use other adjustments
+ in future to be (forward) compatible with systems that support
+ wider exit status values as discussed at
+ http://austingroupbugs.net/view.php?id=947 */
+
char *endp;
long int l = (errno = 0, strtol (operand, &endp, 10));
int i = l;
diff --git a/tests/misc/kill.sh b/tests/misc/kill.sh
index 27d550e..779ce3e 100755
--- a/tests/misc/kill.sh
+++ b/tests/misc/kill.sh
@@ -49,10 +49,15 @@ env kill -t TERM HUP || fail=1
SIGTERM=$(env kill -l HUP TERM | tail -n1) || fail=1
test $(env kill -l "$SIGTERM") = TERM || fail=1
+# Verify we only consider the lower "signal" bits,
+# to support ksh which just adds 256 to the signal value
+STD_TERM_STATUS=$(expr "$SIGTERM" + 128)
+KSH_TERM_STATUS=$(expr "$SIGTERM" + 256)
+test $(env kill -l $STD_TERM_STATUS $KSH_TERM_STATUS | uniq) = TERM || fail=1
+
# Verify invalid signal spec is diagnosed
-SIGINVAL=$(env kill -t | tail -n1 | cut -f1 -d' ')
-SIGINVAL=$(expr "$SIGINVAL" + 1)
-returns_ 1 env kill -l "$SIGINVAL" 0 || fail=1
+returns_ 1 env kill -l -1 || fail=1
+returns_ 1 env kill -l -1 0 || fail=1
returns_ 1 env kill -l INVALID TERM || fail=1
Exit $fail
--
2.5.0
