Mark Dickinson added the comment:

Relying on things like int64_t or uint64_t is tricky, both in principle *and* 
in practice.

C99 (7.18.1.1) 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.

----------
nosy: +skrah

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17884>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to