Hi folks.

While working on an in-house application that uses the curses
module, we noticed that it didn't work as expected on an AIX system
(powerpc 64-bit big-endian LP64), using python 2.3.5.

On a hunch, I took a look through the _cursesmodule.c code and
noticed the use of PyArg_ParseTuple()'s "l" decoding mode to retrieve
a "long" from python into a C type (attr_t) that on AIX is an int.
On 64-bit LP64 platforms, sizeof(long) > sizeof(int), so this
doesn't quite work, especially on big-endian systems.

Further research into curses shows that different platforms use a
different underlying C type for the attr_t type (int, unsigned int,
long, unsigned long), so changing the PyArg_ParseTuple() to using
the "i" decoding mode probably wasn't portable.

I documented this problem and provided a patch that fixes it against
the head of the svn trunk in http://bugs.python.org/issue1114
(because the problem appears to still exist in the latest code.)

My workaround was to use a separate explicit C "long" to decode
the value from python into, and then just assign that to the
final value and hope that the type promotion does the right thing
on the native platfomr.

My questions are:

 (a)    What's the "preferred" style in python extension modules
        of parsing a number from python into a C type, where the
        C type size may change on different platforms? 
        Is my method of guessing what the largest common size
        will be (long, unsigned long, ...), reading into that,
        and assigning to the final type, acceptable?

 (b)    Is there a desire to see the standard python C extension
        modules cleaned up to use the answer to (a), especially
        where said modules may be susceptable to the word
        size problems I mentioned?
        (64bit big-endian platforms such as powerpc and sparc64
        are good for detecting word-size lossage)


cheers,
Luke.

Attachment: pgpuVGvyDmpHK.pgp
Description: PGP signature

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to