[Victor]

> Ok, I think I understood the issue :-) The problem is when the uint32_t
> type is present but is not exactly 32-bit width.

No, that's still not the issue :-). In any case, it would be a fairly serious violation of C99 to use uint32_t for something that *wasn't* exactly 32 bits in width.  More generally, padding bits, trap representations, and non two's complement representations for signed integers seem to be a thing of the past;  having integer types be exact width seems to be one of the few things that we *can* reasonably rely on.

Concentrating on uint32_t for specificity, there are essentially three cases:

(1) The platform (either in stdint.h or inttypes.h) #defines uint32_t.

(2) The platform (either in stdint.h or inttypes.h) makes a typedef for uint32_t.

(3) The platform doesn't do (1) *or* (2), but nevertheless, there's an unsigned integer type that has exact 32-bit width (and it's probably called "unsigned int").

[Oh, and (4) Windows.  Let's leave that out of this discussion, since there don't seem to be any Windows-specific problems in practice here, and we don't use autoconf.]


We've encountered all three of these cases, and as far as I know in recent history we haven't encountered a platform that doesn't match at least one of these three cases.

With respect to the autoconf and pyport machinery:

In case (1): AC_TYPE_UINT32_T does nothing, because uint32_t is already available, while the
AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T.

In case (2): AC_TYPE_UINT32_T still does nothing, and again AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T.

In case (3): AC_TYPE_UINT32_T #defines uint32_t to be the appropriate type, and AC_CHECK_TYPE(uint32_t) will fail.

So cases (1) and (3) lead to uint32_t being #defined, while cases (1) and (2) lead to HAVE_UINT32_T being defined.  We want to catch all 3 cases, so we have to check for *both* uint32_t and HAVE_UINT32_T in pyport.h.


Note that using AC_TYPE_UINT32_T and checking whether uint32_t is defined is not enough on platforms that do (2): because uint32_t is a typedef rather than a #define, there's no easy way for pyport.h to find it.  Prior to the issue #10052 fix, we assumed that any platform doing (2) would, following C99, also define UINT32_MAX, but that turned out not to be true on some badly-behaved platforms.