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.