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
-~----------~----~----~----~------~----~------~--~---
