[issue17884] Try to reuse stdint.h types like int32_t

STINNER Victor report at bugs.python.org
Mon May 6 14:22:14 CEST 2013


STINNER Victor added the comment:

2013/5/6 Mark Dickinson <report at bugs.python.org>:
> 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").

So in all these 3 cases, it is possible to use "uint32_t" in the code.

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

Windows issues can be fixed in PC/pyconfig.h.

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

Sorry I still don't understand why do you need HAVE_UINT32_T define.
According to what you wrote above, uint32_t can always be used on any
platform.

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

Why should Python do extra checks in pyport.h (ex: check if UINT32_MAX
is available)? Can't we rely on stdint.h?

If stdint.h is not available, we can ask configure to build it for us
using AX_CREATE_STDINT_H. Oh, it looks like this macro is not part of
autotools directly. It's a third party module released under the GNU
GPLv3+ license. Can we include a GPL script in our tool chain? I
contacted the author by email to ask him if we can distribute it under
a different license (compatible with the Python license).

http://www.gnu.org/software/autoconf-archive/ax_create_stdint_h.html
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_create_stdint_h.m4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17884>
_______________________________________


More information about the Python-bugs-list mailing list