Bug summary

_path.is_sorted always reads data from the buffer in native byteorder, thus it can give incorrect results when the input is in non-native byteorder. (This is also true for is_sorted_and_has_non_nan in #25978.)

Code for reproduction

# The array below reads as [2, 256] after byteswapping.
mpl._path.is_sorted(np.array([33554432, 65536], ">i4"))

Actual outcome

True

Expected outcome

False

Additional information

We don't actually really need to support any case other than native-order floats in is_sorted (because we only ever call it with a freshly constructed float array), so we should just restrict support to that case.
It may also be useful to inspect the other C APIs which may likewise be impacted by wrong byteorderness.

I also doubt that the speed gain from having a specialized C implementation of is_sorted (compared to the plain numpy nanmask = np.isnan(x); x_finite = x[~nanmask]; x_finite.size and (x_finite[1:] >= x_finite[:-1]).all() or similar -- note that we already compute nanmask and x_finite below) is really worth the trouble.

Operating system

macos

Matplotlib Version

3.8.0.dev1128+g5438e94fa7

Matplotlib Backend

any

Python version

3.11

Jupyter version

No response

Installation

git checkout