Martin v. Löwis <mar...@v.loewis.de> added the comment: > 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)) ---------- title: Specification of Py_CHARMASK -> 2.7: eval hangs on AIX _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9020> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
