> What srid seems to be saying is that chars are unsigned on AIX, and
> therefore Py_CHARMASK() returns -1. Hence his patch proposal.

Ah, ok. I misread some of the messages (and got confused by msg108125,
which seems to suggest that chars are signed on AIX).

> Of course, it is dubious why EOF is not tested separately rather than
> passing it to Py_ISALNUM(). Micro-optimization? At least a comment
> should be added.

No, I think this is an error that EOF is not processed separately.
Otherwise, char 255 may be confused with EOF.

Of course, this would have to be done throughout.

> Also, really, the Py_CHARMASK() macro seems poorly specified. It
> claims to "convert a possibly signed character to a nonnegative int",
> but this is wrong: it doesn't convert to an int at all. Furthermore,
> it does a cast in one branch but not in the other, which can give bad
> surprises as here.

I think the specification is correct: it ought to convert to a
non-negative int. In the signed char case, it already returns an int.
So if it is changed at all, it needs to be changed, in the unsigned
case, to

#define  Py_CHARMASK(c)		((int)(c))