[Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]

[Hanno Schlichting]

On Sat, Jul 25, 2009 at 8:01 PM, Shane Hathaway<shane at hathawaymix.org> wrote:
> Hanno Schlichting wrote:
>>
>> I kind of suspect that we are seeing the results of
>> http://www.python.org/dev/peps/pep-0353 though.
>
> That is very likely.  BTW, that PEP links to a handy tool that reveals most
> 64 bit portability issues in Python-oriented C code.

Right, I've given that a shot and it reports plenty of problems for
Acquisition.c for example. In addition to the general compiler
warnings it spits out, which don't tell me much.

>> From what I understand we need to change code in C extension modules
>> following the instructions in that PEP, to be able to run code
>> reliably on 64-bit platforms. To my knowledge nobody changed any C
>> code in Zope yet to do so.
>
> We fixed the C portability problems in Zope 3 a while back, but it seems we
> didn't fix the extensions that are specific to Zope 2.

How thorough has that been? I can see the Py_ssize_t in some of the c
files in zope.* packages, but looking for example at:

http://svn.zope.org/zope.proxy/trunk/src/zope/proxy/_zope_proxy_proxy.c?rev=95468&view=markup

I see a stuff like this:

PyObject *
WrapperType_Lookup(PyTypeObject *type, PyObject *name)
{
  int i, n;

  [...]

  n = PyTuple_GET_SIZE(mro) - 1;

  [...]
}

where PyTuple_GET_SIZE is defined to return a Py_ssize_t and not an int.

Either I misunderstand something here or I was just "lucky" to find
something like this as my first test.

>> The other interesting bit to this is, that it seems doable but hard to
>> do these changes while preserving compatibility with Python 2.4. These
>> changes along with the definition of "Py_ssize_t" were introduced into
>> Python 2.5.
>
> Preprocessor macros solve that fairly cleanly, actually:
>
> #ifndef Py_ssize_t
> #define Py_ssize_t int
> #endif

Ah ok. I was more concerned about the function pointer changes.
intargfunc to ssizeargfunc and so on. I wasn't sure if these are as
easy to redefine as simple data types.

>> At this point I think we need to declare 64-bit platforms as
>> unsupported. Hopefully people with the right kind of knowledge would
>> like to step up and start working on these issues.
>
> I just checked in some code that solves the portability problem in
> zope.index, although I haven't created a release.  It looks like the
> Acquisition module needs some 64 bit TLC.

Cool! I kinda suspect that specific code is also somewhere in Zope2 in
the PluginIndexes where it has been ported from recently.

Hanno