[Hye-Shik Chang] > 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. We do not, and C doesn't guarantee that any such types exist. For example, while the Crays we recently talked about do support the illusion of 8-bit char, they have no 16-bit or 32-bit integral types (just 8 and 64); that's fine by the C standard. C99 defines a large pile of names, for things like "exactly 16 bits *if* such a thing exists", "smallest integral type holding at least 16 bits (this must exist)", and "fastest integral type holding at least 16 bits (which also must exist)". Since not all C compilers support these names yet, they can't be used directly in Python. If one is needed, it's intended to be added, in pyport.h, following this comment: /* typedefs for some C9X-defined synonyms for integral types. * * The names in Python are exactly the same as the C9X names, except * with a Py_ prefix. Until C9X is universally implemented, this is the * only way to ensure that Python gets reliable names that don't * conflict with names in non-Python code that are playing their own * tricks to define the C9X names. * * NOTE: don't go nuts here! Python has no use for *most* of the C9X * integral synonyms. Only define the ones we actually need. */ > ... > If we have types like u_int32_t, it will be very helpful to cope > with these sort of issues. Not really -- any use of an "exactly N bits" name will make the code uncompilable on some platform.
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