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 mark.dickinson
Recipients Devin Jeanpierre, mark.dickinson, skrah, vstinner
Date 2013-05-01.11:50:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Relying on things like int64_t or uint64_t is tricky, both in principle *and* in practice.

C99 ( specifies that the types are optional, but that if the implementation provides types with the appropriate characteristics then the typenames should exist.  I think we could probably get away with assuming the existence of uint32_t and int32_t and smaller types, but uint64_t and int64_t may be a stretch, particularly on ARM-style platforms.

In practice, we've had significant difficulties in the past simply finding and identifying exact-width types in our autoconf machinery:  whether they're defined in <inttypes.h> or <stdint.h> seems to vary from platform to platform, as does whether they're defined as typedef's or preprocessor macros.  I *think* that since the issue #10052 fix, the current autoconf machinery is now fairly good at finding those types across platforms, but I wouldn't want to make any bets.

I do agree that in principle it would be nice to define conversions for the fixed-width types and have everything else defer to those.

There's also some cleanup to be done with respect to semantics;  I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like.  If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms.

I'd be quite happy to see fixed-width conversion functions that *completely ignore* __int__ and __index__, and leave the magic stuff to general PyNumber_... functions.

Adding skrah to the nosy, since this is something I think he's spent some time thinking about, too.
Date User Action Args
2013-05-01 11:50:28mark.dickinsonsetrecipients: + mark.dickinson, vstinner, Devin Jeanpierre, skrah
2013-05-01 11:50:28mark.dickinsonsetmessageid: <>
2013-05-01 11:50:28mark.dickinsonlinkissue17884 messages
2013-05-01 11:50:27mark.dickinsoncreate