BUG: Clipping code assumes alignment % itemsize == 0

[seberg]

The clipping code contains lines like:

        npy_intp is1 = steps[0] / sizeof(T), os1 = steps[3] / sizeof(T);

NumPy guarantees that ufunc data is aligned, but NumPy does not guarantee that alignment is equal to the itemsize. (in particularly, that is clearly not true for complex numbers)

As the quick fix: The code shouldn't use this pattern at all, I think.

But even if we ignore complex (because clipping and complex are weird), do platforms even guarantee that for the basic numerical types? Should code at least have a static_assert() or so if using such a pattern?

(xref gh-26280 because that is why I noticed)

[pijyoi]

NumPy guarantees that ufunc data is aligned, but NumPy does not guarantee that alignment is equal to the itemsize.

My understanding of the code in question is that it is only assuming that items are spaced in multiples of the itemsize. i.e. steps[0] % sizeof(T) == 0
If the starting pointer was aligned, then all subsequent accesses would also be aligned.

Does NumPy not provide those guarantees on entry to the clip function?
If not, it wouldn't even be safe to dereference elements on processors that don't allow misaligned access?

[seberg]

it wouldn't even be safe to dereference elements on processors that don't allow misaligned access

No, it guarantees alignment, which is good enough for that. But alignment can be smaller than itemsize.

[mhvk]

But alignment can be smaller than itemsize.

So the above code would also fail for longdouble (assuming alignment on 8 byte boundaries).

I agree we should avoid the pattern altogether, especially since for most other ufuncs, we explicitly keep the pointers and just add the step to it.

[seberg]

Closing, the speedup PR included the fix.