Marc-Andre Lemburg <m...@egenix.com> added the comment:
Daniel Stutzbach wrote:
>
> Daniel Stutzbach <dan...@stutzbachenterprises.com> added the comment:
>
> On Sat, May 8, 2010 at 10:16 AM, Marc-Andre Lemburg
> <rep...@bugs.python.org> wrote:
>> Are you sure this doesn't get optimized away in practice ?
>
> I'm sure it doesn't get optimized away by gcc 4.3, where I tested it. :)
>
>> Sure, though, I don't see how this relates to C code relying
>> on these details, e.g. a C extension will probably use different
>> conversion code depending on whether UCS2 or UCS4 is compatible
>> with some external library, etc.
>
> Can you give an example?
>
> All of the examples I can think of either:
> - poke into PyUnicodeObject's internals,
> - call a Python function that exposes Py_UNICODE or PyUnicodeObject
>
> I'm explicitly trying to protect those two cases. It's quite possible
> that I'm missing something, but I can't think of any other unsafe way
> for a C extension to convert a Python Unicode object to a byte string.
One of the more important cases you are missing is the
argument parser in Python:
Py_UNICODE *x;
Py_ssize_t y;
PyArg_ParseTuple(args, "u#", &x, &y);
This uses the native Py_UNICODE type, but doesn't rely on any
Unicode APIs.
Same for the tuple builder:
args = Py_BuildValue("(u#)", x, y);
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8654>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
