On Wed, 2003-09-17 at 20:22, Tim Peters wrote:
It could be, but if so Jeremy is running on a mainstream Linux+gcc platform and then it's something we can't really wish away. Jeremy, can you tell us what Py_UNICODE resolves to on your box, or give enough details so someone else can figure it out?
As I read the C standard,
unsigned_int < 256
has to use unsigned comparison, so it's a compiler bug, or I'm misreading the standard, or Jeremy was mistaken in believing Py_UNICODE resolves to an unsigned thingie on his box (we know for sure that the bit pattern 0xcdcdcdcd compared less than 256 on his box; that's obviously what it should do if Py_UNICODE resolves to a signed 4-byte thing on his box, but not otherwise).
I was a little confused by the various UNICODE macros. (Is there a comment block somewhere that explains what they are for?) gcc -E tells me: typedef unsigned int Py_UCS4; typedef wchar_t Py_UNICODE; typedef long int wchar_t; (not necessarily in that order) I got Py_UCS4 and Py_UNICODE confused. The detailed output confirms that Py_UNICODE is a signed long int. Jeremy