This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Devin Jeanpierre, mark.dickinson, skrah, vstinner
Date 2013-05-06.12:22:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwbJfs_dKFm4uN4NhwxSx3aSthrSbhC0yuMsPS07DAYxAA@mail.gmail.com>
In-reply-to <1367831610.48.0.89026379115.issue17884@psf.upfronthosting.co.za>
Content
2013/5/6 Mark Dickinson <report@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
History
Date User Action Args
2013-05-06 12:22:14vstinnersetrecipients: + vstinner, mark.dickinson, Devin Jeanpierre, skrah
2013-05-06 12:22:14vstinnerlinkissue17884 messages
2013-05-06 12:22:14vstinnercreate