gh-92347: Throw a warning when converting a pointer to an iterator

[rruuaanng]

Similar to #92262. I think we should fix this (by setting tp_iter to None) but only on the main branch in case people rely on calling next() on a pointer object.

cc @JelleZijlstra

Since it is implemented in an extension, I added an exception when getting it. Do you think?

• Issue: Iterating over ctypes pointer causes hang or segmentation fault #92347

---

📚 Documentation preview 📚: https://cpython-previews--126318.org.readthedocs.build/

[rruuaanng]

It actually kind of overwhelmed me, the added exception also caused the CI to fail.

from test_ctypes/test_values.py

 class struct_frozen(Structure):
_fields_ = [("name", c_char_p),
("code", POINTER(c_ubyte)),
("size", c_int),
("is_package", c_int),
]
FrozenTable = POINTER(struct_frozen)
modules = []
for group in ["Bootstrap", "Stdlib", "Test"]:
ft = FrozenTable.in_dll(pythonapi, f"_PyImport_Frozen{group}")
# ft is a pointer to the struct_frozen entries:
for entry in ft:
# This is dangerous. We *can* iterate over a pointer, but
# the loop will not terminate (maybe with an access
# violation;-) because the pointer instance has no size.
if entry.name is None:
break

Do note that indexed access to pointer objects is a documented (and useful) behavior. It would be quite surprising to have a sequence-like object raise an exception when used in a for loop, typing constructs notwithstanding.
Perhaps a note in the Pointers section mentioning the unbounded behavior when iterating aka an infinite generator.

Maybe we can just change the document.

[erlend-aasland]

Please do not propose PRs prematurely like this. Moreover, test your changes locally before proposing the fix. If you are uncertain how the CI will react, test your changes using a PR on your own fork first.