BUG: Initialize value of no_castable_output used in ufunc_loop_matches

[alexhenrie]

ufunc_loop_matches checks if (!(*out_no_castable_output)), but out_no_castable_output was not initialized and could be anything.

[seberg]

Hmm, shouldn't valgrind notice this type of thing? I am wondering if we want to add a test for it, because I do not recall valgrind ever complaining about it (I run it semi-rgularly). OTOH, the type_tuple_type_resolver is a bit obscure and not used much (it is the dtype= argument and especially signature= to ufuncs).

Maybe just going to merge this as is soon. Just curious are these PRs based on static code analysis?

[alexhenrie]

I made this pull request and #18156 because of scan-build warnings. #18161 was just something I noticed while looking through the code.

[seberg]

Thanks, I will just merge this. It doesn't seem to fix an actual bug, but is correct.

Whether or not this causes undefined behaviour seems to not make a difference in this function (because it is used solely for error reporting, and that branch doesn't do nice error reporting). (This function is a mess, but I hope the solution is to just delete all of it in the next months.)