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
|