[Python-Dev] Re: python/dist/src/Objectsunicodeobject.c, 2.204,
perky at i18n.org
Mon Dec 22 12:26:25 EST 2003
On Mon, Dec 22, 2003 at 10:50:24AM -0600, Skip Montanaro wrote:
> >> Sounds like a plan. I modify my local source and see if it affects
> >> anything.
> Tim> It should work fine.
> Done. UCHAR_MAX is now required in Python.h, and it's required to be 255.
> That may open up a couple (small) optimization opportunities (places where
> gcc 3.3 says explicit tests against char values will always be true or
> false).I'll leave it for others to make those tweaks if they so desire.
> Note that some of those gcc messages are probably related to larger types
> (e.g. unsigned short) or depend on the presence or absence of other macro
> definitions (e.g. Py_UNICODE_WIDE). Should you wish to code any of these
> speedups, make sure you get the cpp tests right. Guido won't forgive you if
> you don't. <wink>
I see. Hehe :-)
BTW, I wonder whether we have any good way to get C integer types
with explicitly defined size such as u_int16_t or int64_t of POSIX.
I got a report from an OpenBSD/sparc64 user that he want to change
an unsigned int variable to int type which is used for socket.inet_aton.
(Modules/socketmodule.c:2887). But I think int type isn't appropriate
due to fearing its being 64-bits on some 64bit platforms. Also
in_addr_t, POSIX return type of inet_addr(3), is not so portable.
If we have types like u_int32_t, it will be very helpful to cope
with these sort of issues.
More information about the Python-Dev