[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Marc-Andre Lemburg]

Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>>  * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>>
>>  * in order to make the macro easier to understand, please rename it to
>>  Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still
>>  a lot less than without the macro :-)
> 
> I am not sure Py_UCS4_ prefix is right here.  (I agree on *SURROGATE*
> methods.)  The point of Py_UNICODE_NEXT(ptr, end) is that the pointers
> ptr and end are Py_UNICODE* and the macro expands to *p++ on wide
> builds.  Maybe Py_UNICODE_NEXT_USC4?

The idea is that the first part refers to what the macro returns (Py_UCS4)
and the "read" part of the name refers to moving a pointer across
an array (any array of integers).

Note that the macro can also work on Py_UCS4 arrays (even in
UCS2 builds), so it's universal in that respect.

Perhaps we should allow ord() to work on surrogates in
UCS4 builds as well. That would reduce the number of
surprises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________