[Python-Dev] Collection of typedefs for integral types

[Tim Peters]

[Guido]
> C already *has* a sane collection of typedefs: short, int, long, maybe
> combined with unsigned.

Those aren't typedefs, they're types, and the direct use of them was the
cause of almost all of Trent Mick's Win64 porting pains.  The std makes very
weak promises about the std integral types, and Python (like all other C
code that uses them directly!) accumulated lots of unwarranted assumptions.
Rather than fix this with sane typedefs, we're now getting increasing
amounts of ugly and brittle #ifdef'ed code keying off preprocessor symbols
(like SIZEOF_LONG etc).

> Plus size_t and so on.

Those are typedefs.  C9X adds more of that ilk, like "integral type big
enough to hold a casted pointer", which current C doesn't address at all
beyond guaranteeing there's *some* (unnamed) suitable type (and the lack of
a typedef for which in Python accounted for maybe half of Trent's patches).

> There should be only relatively few places where these aren't
> sufficient:  the most common case being when you need the smallest type
> that's at least 32 bits, which on some systems is spelled as long, on
> others as int.

Agreed, and that's specifically what this patch needs (provided Bill gets
over his paranoia <wink>).

> When you need exactly 32 bits, you're out of luck (e.g. on Crays, it
> seems, if Tim is right).

That sizeof(short) == 8 is in part why Python's long ints are currently
broken on the J90 (the other reason is that the J90 has the only compiler I
know of that does not generate code to sign-extend right shifts of signed
integral types).

> So it would be better not to write code that depends on exactly 32 (or
> 16, or 64, or 27) bits.  Places where you just *have* to have exactly
> 32 bits are rare -- perhaps the calculation of 32-bit checksums is
> commonly done this way, but even there I would expect that it's
> possible to write the code to be correct for larger int sizes as well.

Absolutely:  the new crc32 checksum in Python was written this way (to
require ints at least 32 bits, but tolerate ints larger than that).  It is
not, however, good that the code *spells* that requirement "unsigned long"!
As obscure as can be.

My position remains the same:  adopt the C9X names for as many of the new
integral synonyms as we *need*, but stick "Py_" in front of them.

the-committee-wasn't-just-jerking-off-the-last-10-years<wink>-ly y'rs  - tim