Tim Peters wrote: > [M.-A. Lemburg] > >>Note that the implementation will bomb in several places if >>Py_UNICODE is a signed type. >> >>Py_UNICODE was never intended to be a signed type, so the proper >>fix would be to add logic so that Py_UNICODE gets forced to be an >>unsigned type. > > Jeremy believed Py_UNICODE 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 <wink>. 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 Py_UNICODE could become signed is via >>a compiler that defines wchar_t to be signed -- rather unlikely. > > The C standard requires wchar_t 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 Py_UNICODE 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 ! ::::
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