BUG: fix data race in np.repeat
#28203
Conversation
|
Should this be backported? My intent in 2.2.x is to get free threading and typing to a more finished state. |
|
Thanks for checking, I think this one should be safe to backport. |
| @@ -922,16 +922,23 @@ PyArray_Repeat(PyArrayObject *aop, PyObject *op, int axis) | |||
| } | |||
| } | |||
|
|
|||
| /* Fill in dimensions of new array */ | |||
| npy_intp dims[NPY_MAXDIMS] = {0}; | |||
There was a problem hiding this comment.
| npy_intp dims[NPY_MAXDIMS] = {0}; | |
| npy_intp dims[NPY_MAXDIMS]; |
No need to zero 64 (any) elements.
But looks all good to me, thanks!
There was a problem hiding this comment.
I was taught to always zero-initialize as a defensive programming practice and it makes easier for me to reason about code if I know that instead possibly getting garbage when I dereference a pointer or read a variable, I get a sensible default.
Just to give you some context why I send in code that does that. I'm probably going to continue doing it because it's how I was taught to write C and C++. In the future, if you can give me more context about why you think I shouldn't do it besides "it's unnecessary" I'd appreciate it. I know it's unnecessary if everything is bug-free, it's to make the behavior more predictable if there is a bug.
There was a problem hiding this comment.
🤷 maybe I should do it more. Although not sure I'll be convinced of it here when the initialization is right below it and any random value is just as wrong as 0 :).
(I wish that the compiler warnings and sanitizers were better about uninitialized stack usage, at which point I would clearly prefer the warning.)
Fixes #28197.
The change to
run_threadedis unrelated but needed for the way I wrote the test to avoid duplicating keyword arguments. My fault for introducing two keywords that do the same thing 🙃.