A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-July/026259.html below:

[Python-Dev] The C API and wide unicode support

[Python-Dev] The C API and wide unicode supportM.-A. Lemburg mal@lemburg.com
Wed, 10 Jul 2002 19:19:12 +0200
Michael Hudson wrote:
>>Shouldn't only functions whose signature uses PY_UNICODE_TYPE be
>>>name-mangled?  What am I missing?
 >
>>What about the functions that use the C macros (PyUnicode_AS_UNICODE
>>etc.) directly or indirectly? Those functions will rely on the
>>internal lay-out.
> 
> 
> They're verboten in extension modules anyway, so I don't care.

They are not disallowed in extensions... don't know where you
have that idea from.

Note that the name mangling is done to prevent an extension
which uses Unicode in some way from loading if the interpreter
and extension Unicode "width" doesn't match.

If we would allow this, extensions using the macros would cause
memory corruption since they'd index differently. That's not only
a potential cause for a seg fault, it's also a security risk.

The name mangling does not provide a 100% bullet proof way
of preventing this (an extension might use Py_UNICODE and
the Unicode macros without touching any of the other C APIs),
but it goes a long way in that direction.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4