[Patches] [ python-Patches-925932 ] struct.pack() on 64bit
architectures
SourceForge.net
noreply at sourceforge.net
Wed Mar 31 14:08:15 EST 2004
Patches item #925932, was opened at 2004-03-30 12:55
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=925932&group_id=5470
Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aleksander Piotrowski (pelotas)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.pack() on 64bit architectures
Initial Comment:
I'm running python on OpenBSD/sparc64 (SUN Ultra 10).
On this machine struct.pack() gives me:
>>> struct.pack('l', 1)
'\x00\x00\x00\x00\x00\x00\x00\x01'
>>> struct.pack('i', 1)
'\x00\x00\x00\x01'
On i386 box I have:
>>> struct.pack('l', 1)
'\x01\x00\x00\x00'
>>> struct.pack('i', 1)
'\x01\x00\x00\x00'
Because of this, OpenBSD port uses attached patch. I
guess that this is generic problem (not OpenBSD
specific) and every 64bit platform would suffer.
Am I right?
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2004-03-31 21:08
Message:
Logged In: YES
user_id=21627
I don't quite understand the current code: struct flock is
on Darwin
struct flock {
off_t l_start; /* starting offset */
off_t l_len; /* len = 0 means until end
of file */
pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write,
etc. */
short l_whence; /* type of l_start */
};
and off_t is
typedef int64_t quad_t;
typedef quad_t off_t; /* file offset */
so it appears there is no padding at all. In any case,
this needs to be changed in posixfile._posixfile_.flock
accordingly.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-03-30 17:57
Message:
Logged In: YES
user_id=31435
For a Unix-head reviewer: the patch is to test_fcntl.py,
which uses a native struct.pack() to build a lockdata
argument for fcntl. On the OP's box, it constructs stuff of
the wrong size, due to "l" format codes producing 8-byte
thingies. The patch changes the "l" codes to "i" on the OP's
platform.
I wonder whether we couldn't instead use "i" codes on all BSD-
ish platforms -- on 32-bit boxes, "i" is synonymous with "l",
while on 64-bit boxes it looks like "l" is wrong but "i" is correct.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=925932&group_id=5470
More information about the Patches
mailing list