segfault: `QuadPrecision(1).byteswap()`

[jorenham]

It seems to happen every time:

❯ python -m IPython
Python 3.13.9 (main, Oct 14 2025, 21:29:44) [Clang 20.1.4 ]
Type 'copyright', 'credits' or 'license' for more information
IPython 9.6.0 -- An enhanced Interactive Python. Type '?' for help.
Tip: You can use LaTeX or Unicode completion, `\alpha<tab>` will insert the α symbol.
Ctrl click to launch VS Code Native REPL

In [1]: import numpy_quaddtype as npq

In [2]: npq.QuadPrecision(1).byteswap()
[1]    1076585 segmentation fault (core dumped)  python -m IPython

For the numpy floating types this byteswap() is a no-op, I believe.

[SwayamInSync]

I need to inspect the cause of byteswap, but it seems to be working for np.float64 so we should also be supporting this

In [3]: np.float64(1.2)
Out[3]: np.float64(1.2)

In [4]: np.float64(1.2).byteswap()
Out[4]: np.float64(4.667261458438315e-62)

In [5]: np.float64(1.2).byteswap().byteswap()
Out[5]: np.float64(1.2)

Thanks for catching this, you're exploration of quaddtype really helped us finding these bugs

[SwayamInSync]

@seberg why copyswap and copyswapn are disabled?
https://github.com/numpy/numpy/blob/6cf1fddea79029c238dbd3c165b45132d2f1f867/numpy/_core/include/numpy/dtype_api.h#L416

[seberg]

Because it should be using the normal cast, I think. Does it crash not trying to call a NULL copyswap (it's possible that it is a whole)? You could try to not support it, giving the dtype a | byte-order. A problem would be moving data between different architectures, though (i.e. no way to load data dumped on another architecture).

[SwayamInSync]

It seems to be crashing when calling copyswap as per gdb

PyDataType_GetArrFuncs(descr)->copyswap(newmem, data, 1, NULL);

and the value there is NULL

You could try to not support it,

So by default on big-endian, quaddtype itself handles this internally and works as expected. But its just about the support for this function I mean since we have the functionality so we might can support.

One more thing I don't get is why relying on normal cast? is there any design decision taken for this?

[seberg]

Ah, this is byteswap() without a cast. Not sure I like .byteswap() as a first-class thing. The important part to me is that you can cast between them, swapping a dtype without a cast seems rather raw.

I might be tempted to say we should just implement it as a byteswapped cast + view (even if that might reject some dtypes).

But... we still need to allow dtype.newbyteordere() to support all of this. Either by allowing PyArray_DescrNew() (although byte-order is one of the few things you could modify after doing thta!) or an explicit method.
(I think a PyArray_DescrNew() support would basically mean copy()/deepcopy() call, but lower in the sense that a descriptor may be considered immutable for user DTypes, I think, and this explicitly assumes it will be mutated.)

[seberg]

While I think tha ta PyArra_DescrNew() support may make sense just for completeness (some people are interested in mutating alignment too for example), I am not actually sure if I think .byteswap() is very important. Since you probably support QuadDType(byteorder=">") so users have a manual path, the problem is just that .newbyteorder() would be needed to work accross unknown dtypes, though.

[SwayamInSync]

Thanks @seberg for the points, so if I am getting you correctly then

1. You don't want first-class support for copyswap and that is why it is not exposed in current API? (I do wonder why? what's the philosophy behind?)
2. The cast + view i.e. dtype.newbyteorder() calls to the PyArray_DescrNewByteorder which is also not supported for new API

Since you probably support QuadDType(byteorder=">") so users have a manual path

Actually we don't implement this as user-facing right now, its system dependent ONLY (on big-end, it'll be BE and so on) that's why I was wondering to make copyswap as the user-facing option but since that'll require making copyswap a first-class so we might take this approach as well. (I am not sure how many times I've do the conditional check for endian in backend for this 😄 )

[seberg]

You don't want first-class support for copyswap and that is why it is not exposed in current API? (I do wonder why? what's the philosophy behind?)

I don't care, we can add it, but I would like to wane away all ArrFuncs it should be a different mechanism.
That could be a ufunc even or so, but... since casts basically already support this...

But, I think that allowing a QuadDType(byteorder=">") that can be cast to the native byte-order (and the canonical slot/resolve-dtypes does that) is far more useful than arr.byteswap() itself. And... it must be part of he casting to integrate in ufuncs, etc.

So basically, yes, I think you need to start with support in the dtype.

[seberg]

I am not sure how many times I've do the conditional check for endian in backend for this

Ah, yeah, you may need quite a few ensure_canonical calls, that is true. NumPy defaults to that in the resolvers, but I guess you got a lot of custom ones.