The following trivial test program fails on AIX 5.1 because the high
bits are always stipped off $?. Does anybody know why perl does this?
use Test;
plan tests => 2;
use POSIX qw(WIFSIGNALED WTERMSIG);
system($^X . q( -e 'kill(15, $$); sleep(1)'));
print "# \$? = $?\n";
ok(WIFSIGNALED($?));
ok(WTERMSIG($?), 15);
The output of this program is:
$ perl xxx.pl
1..2
# $? = 15
ok 1
not ok 2
# Test 2 got: '0' (xxx.pl at line 9)
# Expected: '15'
The following patch makes this test program succeed:
--- perl.h.orig 2005-05-11 20:35:15.122448664 +0200
+++ perl.h 2005-05-11 20:35:24.397536739 +0200
@@ -2449,8 +2449,6 @@
# define STATUS_POSIX_SET(n) \
STMT_START { \
PL_statusvalue = (n); \
- if (PL_statusvalue != -1) \
- PL_statusvalue &= 0xFFFF; \
} STMT_END
# define STATUS_CURRENT STATUS_POSIX
# define STATUS_ALL_SUCCESS (PL_statusvalue = 0)
and now the output is:
$ ../t1/bin/perl xxx.pl
1..2
# $? = 983055
ok 1
ok 2
The perl test suite still passes both on AIX and Linux with this patch
applied. If nobody can explain the &=0xFFFF then I suggest we just
try to apply it and see what breaks.
FYI: This is how WTERMSIG is defined in /usr/include/sys/wait.h on the
AIX machines we have here:
AIX-4.3.3: #define WTERMSIG(__x) (int)(WIFSIGNALED(__x) ? ((__x) & 0x7f) :
-1)
AIX-5.1: #define WTERMSIG(__x) (int)(WIFSIGNALED(__x) ? ((((unsigned
int)__x) >> 16) & 0xff) : -1)
--
Gisle Aas
