On Thu, Oct 19, 2006 at 10:35:56AM +0200, Pieter Rautenbach wrote: > > This becomes a problem in > > line 58 of > > msnp11chl.py, as the hex representation is now missing an L > > at the end. > > It looks like it's only an issue on 64-bit architectures tough. > > I don't know whether this is purely a 64 bit problem, since executing the > snippets above, Python 2.3.4 on the same 64 bit machine yields the correct > result.
I'm sorry, my description probably got a bit rushed. I was only able to replicate the issue using both Python 2.5 and a 64-bit architecture. The struct.unpack() function does indeed return an int on both 32-bit and 64-bit architectures in Python 2.5. However, on the 32-bit architecture, it seems the values are being cast to a long at a later point in the msnp11chl code - I guess the values become to large to fit in 32-bit at some point (but that they still fit in 64-bit). This is my observations based on the challenge from your logfile - I can't rule out that there will be problems on 32-bit architectures in some other cases. Using earlier versions than Python 2.5 the struct.unpack() function always returns a long on both 32-bit and 64-bit architectures, so in this case there aren't any problems. Best regards, Lars _______________________________________________ py-transports mailing list [email protected] http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
