On Sun, Oct 05, 2008 at 11:41:53AM +0200, Iustin Pop wrote: > i386: result is <type 'long'>, expected is <type 'long'> > amd64: result is <type 'int'>, expected is <type 'long'> > > I don't understand exactly what's going on, but I think the problem is > that an i386 system cannot represent that constant as int, but amd64 can > (not sure why...): > $ python32 -c 'print type(0xffffffff)' > <type 'long'> > $ python64 -c 'print type(0xffffffff)' > <type 'int'> Problem is in struct.unpack function Unpacking "<I" (wire_format.FORMAT_UINT32_LITTLE_ENDIAN) on 32 and 64 bit systems give different types.
$ uname -m i686 $ python -c 'import struct; print type(struct.unpack("<I", "\xff\xff\xff\xff")[0])' <type 'long'> $ python --version Python 2.5.2 $ uname -m x86_64 $ python -c 'import struct; print type(struct.unpack("<I", "\xff\xff\xff\xff")[0])' <type 'int'> $ python --version Python 2.5.2 Decode.ReadSFixed32 and InputStream.ReadLittleEndian32 don't check types and pass value they got from struct.unpack. Possible fix will be converting result of unpack function to fixed type (int or long). Pavel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---