Under AIX (5.1 at least), POLLNVAL (from sys/poll.h)
is 0x8000. This causes a problem because it is stored
in a (signed) short (e.g., revents):
-----
struct pollfd
{
int fd; /* file descriptor or file ptr */
short events; /* requested events */
short revents; /* returned events */
};
-----
As such, the following tests and results are given:
-----
ashort (%hx) = 8000, ashort (%x) = ffff8000
POLLNVAL (%hx) = 8000, POLLNVAL (%x) = 8000
ashort == POLLNVAL => 0
ashort == (short)POLLNVAL => 1
-----
Note that the 'ashort == POLLNVAL' test is 0 rather
than 1 because (I believe) POLLNVAL is treated as a
signed integer, the ashort value is then promoted to
signed integer thus giving 0xffff8000, not 0x8000.
The problem arises because IBM has chosen to use a
negative short value (0x8000) in a signed short
variable. Neither Linux or IRIX have this problem
because they use POLLNVAL=0x20 which promotes to
0x20.
This situation will cause the test_poll to fail and
will certainly be a gotcha for AIX users.
I have added the following code to the selectmodule.c
to address the problem (mask out the upper 32 bits):
-----~ line 513:selectmodule.c
num = PyInt_FromLong(self->ufds[i].revents & 0xffff);
-----
John
|