Message296042
| 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. :) |
|