[Python-Dev] Re: python/dist/src/Objectsunicodeobject.c, 2.204, 2.205

[Hye-Shik Chang]

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.

Thanks!

> 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.


Hye-Shik