[Python-Dev] Re: [Python-checkins] python/dist/src/Objects unicodeobject.c, 2.197, 2.198 (original) (raw)

M.-A. Lemburg mal at lemburg.com
Wed Sep 17 04:08:13 EDT 2003

Tim Peters wrote:

[M.-A. Lemburg]

Note that the implementation will bomb in several places if PyUNICODE is a signed type.

PyUNICODE was never intended to be a signed type, so the proper fix would be to add logic so that PyUNICODE gets forced to be an unsigned type. Jeremy believed PyUNICODE was already an unsigned type on his box, and that was the box with the segfaults. I don't know. Comparison with a signed int confused the issues to the point where we gave up and just fixed it .

That sounds more like compiler bug to me. What's bothering me is that such compares are done in other places too, so a more general solution would be better.

The only case where PyUNICODE could become signed is via a compiler that defines wchart to be signed -- rather unlikely. The C standard requires wchart to be an integer type, but doesn't constrain it further to an unsigned integer type. I don't like relying on non-standard assumptions in cases where there's little-to-no cost in not relying on them. For example, the cast I put in with this patch is probably a nop on most boxes, just forcing an unsigned comparison (which must have been the original intent, if PyUNICODE was assumed to be an unsigned type).

No question there, but wouldn't it be easier to test such a platform and then fallback to "unigned int" in case wchar_t is found to be a signed value ?

-- Marc-Andre Lemburg eGenix.com

Professional Python Software directly from the Source (#1, Sep 17 2003)

Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list