Message 188168 - Python tracker (original) (raw)

Some Google searchs told me that no CPU support 128-bit integer and using 64-bit integer as intmax_t is safe.

GCC has a __int128 type, but I didn't find on which platform it is supported, nor if intmax_t is __int128 in this case.

Microsoft Visual Studio has stdint.h since its version 2010 (which is the version required to compile Python 3.4 on Windows according to the Python developer guide).

I propose a safer definition of Py_intmax_t:

#ifdef HAVE_UINTMAX_T typedef uintmax_t Py_uintmax_t; typedef intmax_t Py_intmax_t;

#elif SIZEOF_SIZE_T >= 8 typedef size_t Py_uintmax_t; typedef Py_ssize_t Py_intmax_t;

#elif defined(HAVE_LONG_LONG) && SIZEOF_LONG_LONG >= 8 typedef unsigned PY_LONG_LONG Py_uintmax_t; typedef PY_LONG_LONG Py_intmax_t;

#else

error "Python needs a typedef for Py_uintmax_t in pyport.h."

#endif

I don't think that a fallback on the long type is required, testing size_t should be enough.

At least, the compilation fails if the Py_intmax_t type cannot be defined.

Having generic PyLong_FromUintMax_t() and PyLong_AsUintMax_t() functions (and signed version) would simplify the support of other OS types with variable size: time_t, clock_t, pid_t, gid_t, uid_t, off_t, etc.