[Python-Dev] Word size inconsistencies in C extension modules

Luke Mewburn lukem at NetBSD.org
Mon Sep 10 01:54:30 CEST 2007


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20070910/734b38ce/attachment.pgp 


More information about the Python-Dev mailing list