segfault: QuadPrecision(1).byteswap() #13

Activity

1. SwayamInSync commented on Oct 27, 2025

   

   SwayamInSync

   on Oct 27, 2025

   Member

   More actions

   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

   ❤️React with ❤️1Reacted by Joren Hammudoglu
2. SwayamInSync commented on Oct 28, 2025

   

   SwayamInSync

   on Oct 28, 2025

   Member

   More actions

   @seberg why copyswap and copyswapn are disabled?
   https://github.com/numpy/numpy/blob/6cf1fddea79029c238dbd3c165b45132d2f1f867/numpy/_core/include/numpy/dtype_api.h#L416
3. seberg commented on Oct 28, 2025

   

   seberg

   on Oct 28, 2025

   Member

   More actions

   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).
4. SwayamInSync commented on Oct 28, 2025

   

   SwayamInSync

   on Oct 28, 2025

   Member

   More actions

   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?
5. seberg commented on Oct 28, 2025

   

   seberg

   on Oct 28, 2025

   Member

   More actions

   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.)
6. seberg commented on Oct 28, 2025

   

   seberg

   on Oct 28, 2025

   Member

   More actions

   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.
7. SwayamInSync commented on Oct 28, 2025

   

   SwayamInSync

   on Oct 28, 2025

   Member

   More actions

   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 😄 )
8. seberg commented on Oct 28, 2025

   

   seberg

   on Oct 28, 2025

   Member

   More actions

   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.
9. seberg commented on Oct 28, 2025

   

   seberg

   on Oct 28, 2025

   Member

   More actions

   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.
10. jorenham

    added the

    Bug

    issue type on Nov 10, 2025
11. SwayamInSync

    added the

    Bug

    issue type on Jan 16, 2026
12. SwayamInSync

    transferred this issue fromnumpy/numpy-user-dtypeson Jan 16, 2026