ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> python-dev
python-dev
Re: [Python-Dev] New PEP: Using ssize_t as the index type
by M.-A. Lemburg other posts by this author
Jan 19 2006 1:19AM messages near this date
Re: [Python-Dev] New PEP: Using ssize_t as the index type | Re: [Python-Dev] New PEP: Using ssize_t as the index type
Neal Norwitz wrote:
>  On 1/10/06, M.-A. Lemburg <mal@[...].com> wrote:
> > We'd also have to make sure that old extensions don't
> > just import with a warning, since the change will introduce
> > buffer overflows and seg faults in extensions that are not
> > aware of the change.
>  
>  I agree that on 64-bit platforms we should prevent the import.  In the
>  past we only provided a warning and the users were on their own.  This
>  is different.
>  
>  If you read my massive checkin to check the return results of
>  Py_InitModule*(), you'll realize this isn't as simple as just failing
>  in Py_InitMethod*().  I was hoping to just modify Py_InitModule4() in
>  Python/modsupport.c to fail and return NULL.  That doesn't seem
>  practical given that we didn't check return results.  We will just
>  crash the interpreter with standard python 2.4 modules.
>  
>  ISTM we need to modify _PyImport_LoadDynamicModule() in
>  Python/importdl.c before calling the init function (line 56, (*p)())
>  to check for some magic symbol that is defined only when compiling 2.5
>  and above.  For example we could add a static int  _64_bit_clean = 1;
>  in modsupport.h.  Without some trickery we will get this defined in
>  every .o file though, not just modules.
>  
>  Other ideas?

We could explicitly break binary compatibility for Python 2.5
on 64-bit platforms, by changing the name of an often used
API, e.g. the Py_InitModule*() APIs.

This is how Unicode does it - we map the various APIs to
either ...UCS2 or ...UCS4, so that you cannot import an
extension compiled for e.g. UCS2 into a Python interpreter
compiled for UCS4. If we didn't, you'd get seg faults and
buffer overflows the same way you would with the ssize_t
change on 64-bit platforms.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 19 2006)
> >> Python/Zope Consulting and Support ...        http://www.egenix.com/
> >> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
> >> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om
Thread:
"Martin v. Löwis"
Travis E. Oliphant
"Martin v. Löwis"
Brett Cannon
Fredrik Lundh
"Martin v. Löwis"
Tim Peters
"Martin v. Löwis"
Armin Rigo
"Martin v. Löwis"
Armin Rigo
"Martin v. Löwis"
M.-A. Lemburg
Neal Norwitz
"Martin v. Löwis"
M.-A. Lemburg
"Martin v. Löwis"
M.-A. Lemburg
"Martin v. Löwis"
M.-A. Lemburg
"Martin v. Löwis"
Tim Peters
"Martin v. Löwis"
Michael Urman
Neal Norwitz
Aahz
"Martin v. Löwis"
Guido van Rossum

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved