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 Devin Jeanpierre
Recipients Devin Jeanpierre, benjamin.peterson, josh.r, mark.dickinson, pitrou, serhiy.storchaka, vstinner
Date 2017-06-14.21:48:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1497476931.66.0.202054133971.issue17870@psf.upfronthosting.co.za>
In-reply-to
Content
> I wrote my first patch in 2013, but I still fail to find a very good example where intmax_t would be an obvious choice. So I have to agree and I will now close the issue.

Hold on, nobody ever answered the question in the OP. How would you convert an intptr_t (e.g. Rust's int type) to a Python int?

You can't use FromVoidPtr because of signedness. You can use FromLongLong, but that's implementation-defined.

If what we should be using is FromLongLong for all "really big ints", why not just rename FromLongLong to FromIntMax and call it a day?



There is no standard relationship between long long and most other int types -- all we know is that it's at least 64 bits, but an int type can perfectly reasonably be e.g. 80 bits or 128 bits or similar. I think it *is* a worhtwhile goal to allow programmers to write C code that has as little implementation-defined or undefined behavior as possible.


If that isn't considered a worthwhile goal, maybe we should reconsider using such a dangerous and pointy language as C. :)
History
Date User Action Args
2017-06-14 21:48:51Devin Jeanpierresetrecipients: + Devin Jeanpierre, mark.dickinson, pitrou, vstinner, benjamin.peterson, serhiy.storchaka, josh.r
2017-06-14 21:48:51Devin Jeanpierresetmessageid: <1497476931.66.0.202054133971.issue17870@psf.upfronthosting.co.za>
2017-06-14 21:48:51Devin Jeanpierrelinkissue17870 messages
2017-06-14 21:48:51Devin Jeanpierrecreate