-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
ENH,API: Store exported buffer info on the array #16938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
c1c4a60
2030884
ee682f6
6c2e8cd
70565ea
3149ad4
89037ab
8cb3efb
803354e
802977b
a216c5b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
Size of ``np.ndarray`` and ``np.void_`` changed | ||
----------------------------------------------- | ||
The size of the ``PyArrayObject`` and ``PyVoidScalarObject`` | ||
structures have changed. The following header definition has been | ||
removed:: | ||
|
||
#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields)) | ||
|
||
since the size must not be considered a compile time constant: it will | ||
change for different runtime versions of NumPy. | ||
|
||
The most likely relevant use are potential subclasses written in C which | ||
will have to be recompiled and should be updated. Please see the | ||
documentation for :c:type:`PyArrayObject` for more details and contact | ||
the NumPy developers if you are affected by this change. | ||
|
||
NumPy will attempt to give a graceful error but a program expecting a | ||
fixed structure size may have undefined behaviour and likely crash. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -701,6 +701,7 @@ typedef struct tagPyArrayObject_fields { | |
int flags; | ||
/* For weak references */ | ||
PyObject *weakreflist; | ||
void *_buffer_info; /* private buffer info, tagged to allow warning */ | ||
} PyArrayObject_fields; | ||
|
||
/* | ||
|
@@ -720,7 +721,18 @@ typedef struct tagPyArrayObject { | |
} PyArrayObject; | ||
#endif | ||
|
||
#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields)) | ||
/* | ||
* Removed 2020-Nov-25, NumPy 1.20 | ||
* #define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields)) | ||
* | ||
* The above macro was removed as it gave a false sense of a stable ABI | ||
* with respect to the structures size. If you require a runtime constant, | ||
* you can use `PyArray_Type.tp_basicsize` instead. Otherwise, please | ||
* see the PyArrayObject documentation or ask the NumPy developers for | ||
* information on how to correctly replace the macro in a way that is | ||
* compatible with multiple NumPy versions. | ||
*/ | ||
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What was wrong with this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nothing as such, but it is a trap, and most code that uses it, such as:
is probably problematic and most likely not be binary compatible with all numpy versions. So it gives a false sense security? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see why, it is defined at compile time just as before. The API is changed anyway, so apps compiled against 1.20 are not guaranteed to be backwards compatible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And code that extends NumPy internals has never been guaranteed to be forward compatible. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. True, this is only interesting for forward compatibility with possible future size changes. I would have a faint hope that it may help someone realize that since their module doesn't compile on 1.20+, it has to be modified even if you compile it with an earlier version to run in 1.20+... I agree, we probably never promised not to modify struct sizes in this way, we have certainly done with many structs (aside from The first version here, I replaced the macro with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But someone who uses this macro currently will incorrectly believe that their code is forward compatible. They are even avoiding the "deprecated API" to ensure binary compatibility with a potential NumPy release messing with the structs internals. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why not just rename it then? Put an underscore on it or something. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At least just comment it out with an explanation of why it is done. The first place people will look for an explanation of trouble will be in the include file. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, let me make this macro a static assert as Matti posted. Even if a compiler should not support it the compiler error will point to some text regarding to what is going on... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, although, I am not sure that actually compiles well always (i.e. without super confusing things). The stack-overflow posts seem to a be a bit unsure about it. Some people seem to suggest the weird:
instead, which is weird, hmmmpf. |
||
/* Array Flags Object */ | ||
typedef struct PyArrayFlagsObject { | ||
|
Uh oh!
There was an error while loading. Please reload this page.