How much work is it to have both npy_intp and npy_size as types? I can imagine this breaking people who are using npy_intp to interact with a C abi using intptr_t, and in the unlikely event these people are on weird systems where there is a difference, they are going to be very annoyed that intp no longer means intptr_t!

We can add a type, the question is what the default should be? I mean, I can also just add nN character code and npy_size, but the question really is what np.intp should map to in Python (and all the C creation functions which create this via NPY_INTP).

I think that:

• For our Python usage, we mean ssize_t in principle. Indices do not need to be pointer sized, they need to be ssize_t sized (same for shapes).
• I am pretty sure we print errors and parse numbers often enough in a way that assumes Py_ssize_t and intp are equivalent. (Not that I am quite sure these all break on OpenVMS)

So my thought here was that actual use is much much closer to size_t. But yes, if your are worried about this and adding a new type of the pointer use-case doesn't seem sufficient, then that is fine...

(+In that case) We should just introduce npy_size now, so that we could do a blanket replace in some 3.0 in a few years in principle.

So, the work-around for users of intptr_t or uintptr_t is to use the character code p or P (which is viable even in C).
I don't love the change for the npyiter allocation, but it seems more correct.

One caveat: I am not sure how one would add the p code to the appropriate integer size. Maybe we don't even want to do that (since otherwise, it would seem to make sense to reorganize the typing long bit-sizes only, if that was easy?).

Depending on how much we worry about making pointer sized integers only available through the 'p' character code (only immediately affecting niche platforms) or dislike the misnomer, this is now ready.

Fixed up the new/modified table to make a not of 'p' as a pointer sized character code at least.
I think this should be final, unless there is worries about changing the meaning, it would be nice to decide that one way or another. (I clearly tend to think that there probably quite a few subtle bugs around this on affected platforms, that forcing those who actually do store pointers to change their code is hopefully good for those platforms in the long run. And maybe more importantly, I think it is good for those who aim to be clean, because unless you have pointers Py_ssize_t makes a lot of things saner, I expect.)

Bleh. If I understand this correctly the question is what do we want npy_intp to represent? size_t is for indexing, and intptr_t is for pointers. From the name, you would think npy_intp is meant to be intptr_t. If we were starting over, we could remove the C typedef, and have a python-level np.size_t and np.intptr_t. But we can't.

I think this is the least bad step forward. The "full" tests failed (due to the flaky tests skipped in #25068) , if they pass I will take another look and merge it.

Hum, after rebasing macos test failed with:

=================================== FAILURES ===================================
______________________ numpy/linalg/tests/test_linalg.py _______________________
[gw2] darwin -- Python 3.10.6 /Users/admin/numpy-dev/bin/python3.10
worker 'gw2' crashed while running 'numpy/linalg/tests/test_linalg.py::TestQR::test_stacked_inputs[complex64-outer_size0-size0]'
=========================== short test summary info ============================
FAILED numpy/linalg/tests/test_linalg.py::TestQR::test_stacked_inputs[complex64-outer_size0-size0]

restarted, but wondering what is up.

Time to give this a shot?

Thanks @seberg