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 

Logged In: YES 
user_id=11375

Applied to 2.4 HEAD; thanks!