By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,715 Members | 768 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,715 IT Pros & Developers. It's quick & easy.

Strange problem with structs Linux vs. Mac

P: n/a
Hi-

I am having a VERY odd problem with unpacking right now. I'm reading
data from a binary file and then using a very simple struct.unpack to
get a long. Works fine on my MacBook, but when I push it to a Linux
box,it acts differently and ends up pewking.

here's the code snippet:
fread.seek(0,0)
tmp_rebuild = fread.read()
fread.close()
tmp_long = tmp_rebuild[0:4]
print tmp_long.encode('hex')
print repr(tmp_long)

unpacked_long = struct.unpack('I', tmp_rebuild[0:4])[0]
print 'unpacked_long: %s' % unpacked_long

my MacBook produces:
1ec6f3b4
'\x1e\xc6\xf3\xb4'
unpacked_long: 516354996

but on the linux box the same code produces:
1ec6f3b4
'\x1e\xc6\xf3\xb4'
unpacked_long: 3035874846

the data looks to be the same, but the unpacking seems to treat it
differently.

Has anyone an idea of why this happens???

Thanks-
J.
Mar 16 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"jasonwiener" schrieb
>
I am having a VERY odd problem with unpacking right now.
I'm reading data from a binary file and then using a very
simple struct.unpack to get a long. Works fine on my MacBook,
but when I push it to a Linux box,it acts differently and
ends up pewking.
[...]

the data looks to be the same, but the unpacking seems to
treat it differently.
Probably little-endian vs. big-endian issue:
>>s
'\x1e\xc6\xf3\xb4'
>>struct.unpack('<I', s)
(3035874846L,)
>>struct.unpack('>I', s)
(516354996L,)

See help(struct) for further information.

This seems to imply that the Mac, although running now on Intel
processors, is still big-endian.

HTH
Martin

Mar 16 '08 #2

P: n/a
On 16 Mar, 18:23, "Martin Blume" <mbl...@freesurf.chwrote:
This seems to imply that the Mac, although running now on Intel
processors, is still big-endian.
Or maybe the struct module thinks big-endian is native to all Macs? It
could be a bug.


Mar 16 '08 #3

P: n/a
"sturlamolden" schrieb
>
This seems to imply that the Mac, although running now
on Intel processors, is still big-endian.

Or maybe the struct module thinks big-endian is native
to all Macs? It could be a bug.
Dunno, I'm on thin ice here. Never used a Mac.
Maybe the underlying C library thinks that all Macs are
big-endian?
I don't think this qualifies as a bug, but I am astonished
that the struct module does not tell you whether you are
big endian, you have to find out yourself with
struct.unpack('@I', s)[0]==struct.unpack(">I", s)[0]

Anyway, when handling binary data across machines, I think
it is proper to explicitly specify the endian-ness and to
do sanity-checking of the results.

Regards
Martin

Mar 16 '08 #4

P: n/a
Completely helped! Working as expected now.

Thanks. You really got me out of a bind!

J.

On Mar 16, 10:23 am, "Martin Blume" <mbl...@freesurf.chwrote:
"jasonwiener" schrieb
I am having a VERY odd problem with unpacking right now.
I'm reading data from a binary file and then using a very
simple struct.unpack to get a long. Works fine on my MacBook,
but when I push it to a Linux box,it acts differently and
ends up pewking.
[...]
the data looks to be the same, but the unpacking seems to
treat it differently.

Probably little-endian vs. big-endian issue:
>s
'\x1e\xc6\xf3\xb4'
>struct.unpack('<I', s)
(3035874846L,)
>struct.unpack('>I', s)

(516354996L,)

See help(struct) for further information.

This seems to imply that the Mac, although running now on Intel
processors, is still big-endian.

HTH
Martin
Mar 16 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.