MAINT: Improve const-correctness of string arguments#15254
MAINT: Improve const-correctness of string arguments#15254mattip merged 1 commit intonumpy:masterfrom
Conversation
6579420 to
7229c46
Compare
7229c46 to
bf0f960
Compare
| { | ||
| Py_ssize_t ucs4len = size / sizeof(npy_ucs4); | ||
| npy_ucs4 *buf = (npy_ucs4 *)src; | ||
| /* FIXME: This is safe, but better to rewrite to not cast away const */ |
There was a problem hiding this comment.
Didn't want to do this rewrite as part of this patch, as it would be hidden amongst the noise
| /* FIXME: Casting away const makes the below easier to write, but should | ||
| * still be safe. | ||
| */ | ||
| npy_ucs4 *s1t = (npy_ucs4 *)s1, *s2t = (npy_ucs4 *)s2; |
There was a problem hiding this comment.
Same as above, didn't want to hide a rewrite amongst a patch that introduces const repeatedly and nothing else
seberg
left a comment
There was a problem hiding this comment.
LGTM, feel free to merge, I will probably do later. Could only try to nitpick comment styles or so, and I do not think its worth it.
Why did you tag it C-API, there is no change here? And if, its an additional const qualifier which is fully compatible (or at least only a warning downstream can adapt to trivially).
|
This is an enhancement to a few public parts of the c API, in that it allows const strings to be passed where previously the could not be. Is the label reserved for incompatible changes? |
|
Dunno, I suppose not. We have not used it much before anyway? I thought to use it mostly for things were people interested in API decisions (but not technical aspects) may want to have a look. And this felt probably unnecessary. |
|
Thanks @eric-wieser |
Using CI to test here because windows compilers aren't strict enough when built by
runtests.py