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