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 skrah
Recipients Devin Jeanpierre, mark.dickinson, skrah, vstinner
Date 2013-05-01.21:58:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20130501215814.GA9859@sleipnir.bytereef.org>
In-reply-to <1367438576.87.0.139810466775.issue17884@psf.upfronthosting.co.za>
Content
Mark Dickinson <report@bugs.python.org> wrote:
> No idea.  Do you have good evidence that 64-bit integer types *will* be
> supported on all platforms that we care about Python compiling on?

I'm not sure how many people have tried to compile Python 3.3 on obscure
platforms, but libmpdec currently requires manual intervention to switch
on the "without uint64_t" mode:

    /* The following #error is just a warning. If the compiler indeed does
     * not have uint64_t, it is perfectly safe to comment out the #error. */
    #error "Warning: Compiler without uint64_t. Comment out this line."

I did this because I'm almost certain that a failure to detect uint64_t is
more likely a ./configure issue than an actual absence of the type.

So far there have been no reports. libmpdec also uses stdint.h directly,
and there haven't been any reports either.

Some commercial Unix buildbots have loads of problems, but support stdint.h,
static inline functions in headers and even the tricky extern inline
C99 functions (See: http://www.greenend.org.uk/rjk/tech/inline.html).

If other developers support it, I'd actually like to write a PEP that allows
unrestricted direct use of stdint.h and static inline functions in header files
for Python 3.4.

My gut feeling is that if a platform doesn't have these features, it will
likely be the least of their problems.
History
Date User Action Args
2013-05-01 21:58:13skrahsetrecipients: + skrah, mark.dickinson, vstinner, Devin Jeanpierre
2013-05-01 21:58:13skrahlinkissue17884 messages
2013-05-01 21:58:12skrahcreate