BUG: avoid uninitialized memory access / NULL-pointer deref in scalar byteswap (#32254) - #32290

PR summary

Fixes #24694

The current scalar byteswap implementation assumes copyswap doesn't need the last argument for the copyswap function, which is an array object. That is incorrect for flexible descriptors (string, void) and for descriptors that request array initialization like object dtype or void dtypes with embedded object dtypes.

For flexible descriptors this allows access to unitialized heap memory on release builds of NumPy or an assert on a debug build:

>>> np.bytes_(b"1234").byteswap()
np.bytes_(b'\xb0\xf5D\x01')
>>> np.array([b"1234"]).byteswap()
array([b'1234'], dtype='|S4')

The first result is uninitialized heap garbage. With a debug build:

>>> import numpy as np
>>> np.bytes_(b"1234").byteswap()
Assertion failed: (arr != NULL), function STRING_copyswap, file arraytypes.c.src, line 2507.
[1]    84175 abort      spin python

If there are object dtypes involved, this bug can also lead to a segfault:

>>> import numpy as np
... o = object()
... s = np.array([(o,)], dtype=[("x", "O")])[0]
... print(s.byteswap()["x"])
...
[1]    84728 segmentation fault  python

(this is also an assert in VOID_copyswap in debug builds).

I could make this less branchy by forcing all dtypes to go through the object dtype path or making e.g. ints, floats, and other simple data dtypes use the stack-allocated array path. I did find leaving the fast-path, even with all the branches, was still worth it. Scalar byteswaps probably aren't performance critical though so I'm open to simplifying this if anyone wants that.

This was originally noticed by @ikrommyd during review of #32150: #32150 (comment)

AI Disclosure

I used an AI for review and to help identify corner cases.