MAINT: const correctness for the generalized ufunc C API - #23847
seberg merged 1 commit into
Conversation
Sorry, something went wrong.
|
If we change it, this is also true for the data (at the right place)? I would prefer having a release note because C++ users might need to add a cast thinking this is ABI relevant (which it is not). |
Sorry, something went wrong.
|
data is a void** --- it's a totally opaque pointer. The Numpy API won't modify it, but the user-provided loop function might. So I think it would make sense to leave data as non-const. |
Sorry, something went wrong.
|
But we promise not to modify it, especially in that function. And I am very sure it must be const, if it wasn't things would fail on current NumPy (the pointer, not its conten in theoryt). So, yes, I think void but void * const* should be right and not matter for C because its OK to cast from non-const to const?) |
Sorry, something went wrong.
OK, I agree. Done. |
Sorry, something went wrong.
The Numpy C API's functions for constructing generalized ufuncs (`PyUFunc_FromFuncAndData`, `PyUFunc_FromFuncAndDataAndSignature`, `PyUFunc_FromFuncAndDataAndSignatureAndIdentity`) take `types` and `data` arguments that are not modified by Numpy's internals. Like the `name` and `doc` arguments, third-party Python extension modules are likely to supply these arguments from static constants. The `types` and `data` arguments are now const-correct: they are declared as `const char *types` and `void *const *data`, respectively. C code should not be affected, but C++ code may be.
|
I also added a changelog entry. |
Sorry, something went wrong.
seberg
left a comment
There was a problem hiding this comment.
Thanks, may slash the release notes down a bit (the main point I want to mention is really that C++ folks may have to cast the function).
Otherwise, just going to sit on it a bit I think, because I going in now might be confusing with an rc in progress.
Sorry, something went wrong.
|
Thanks, let me just put it in. Unlikely that anyone uses C++ in this context, hopefully any confusion will quickly be gone (plus any fixups will probably be necessary either way). |
Sorry, something went wrong.
The types stated in the documentation for the `PyUFunc_FromFuncAndData` and `PyUFunc_FromFuncAndDataAndSignature` has been out of date relative to the header files for a while. After numpy#23847, bring the documentation up to date.
When internally defining ufuncs, declare data and types as const to take advantage of the const correctness of the API. See numpy#23847.
When internally defining ufuncs, declare data and types as const to take advantage of the const correctness of the API. See numpy#23847.
When internally defining ufuncs, declare data and types as const to take advantage of the const correctness of the API. See numpy#23847.
Numpy's internals do not modify this field, and C extensions that call PyUFunc_FromFuncAndDataAndSignature and friends are likely to pass a (static) const char array for the types argument. Make this field const so that calling code does not see discarded qualifier warnings.