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

[Tim Peters]

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