Python.h problem-> /usr/include/python2.2/longobject.h:48: warning: ISO C89 does not support `long long'

[Tim Peters]

[David M. Cooke]
> Well, in C99 it's int64_t (which is guaranteed to be a 64-bit signed
> integer).

Nope, a conforming C99 compiler doesn't have to supply int64_t -- there is
no mandatory integral type in std C guaranteed to be of any specific number
of bits (not 64, 32, 16 or 8 -- all the intNN_t and uintNN_t names in C99
are optional).  "long long" is mandatory in C99, and must be at least 64
bits.

> Or int_least64_t (at least 64 bits)

Nope, that's the narrowest integral type of at least 64 bits.  This must
exist.  Probably the same as long long (which is *an* integral type with at
least 64 bits), but not necessarily (there may be integral types of at least
64 bits narrower than long long).

> or int_fast64_t (native type with at least 64 bits that's the fastest
> of the alternatives).

Yup.  This must exist too.

> Mind you, with GCC they're all typedef'ed to long long int (or long
> int for 64-bit platforms).
>
> Hmm, does PY_LONG_LONG have to be (at least) 64-bits?

That's the intent.

> A quick grep through the source seems to suggest that it's used as
> a large integer type -- not as something that holds at least 64 bits.

For example, the Q format code is supported in the struct module if and only
if PY_LONG_LONG is defined, and in "std mode" holds exactly 8 bytes, so
PY_LONG_LONG has to be at least 8 bytes.