Hi @iliaal. As #20042 (comment) mentions, we generally don't try to fix set_error_handler() clobber issues anymore. In my opinion, this should be fixed in a general way (i.e. something like GH-12805), or not at all.

Hi @iliaal. As #20042 (comment) mentions, we generally don't try to fix set_error_handler() clobber issues anymore. In my opinion, this should be fixed in a general way (i.e. something like GH-12805), or not at all.

Any particular reason (for future reference)? That being said, the change is fairly benign and covers all the by-ref array functions.

Mainly because there are endless ways in which set_error_handler() can cause similar issues, and hunting them down costs resources and hurts code readability to solve an artificial issue. The vast majority of these bugs are found by fuzzers, rather than users.

Fair point, the only reason I tried to tackle it is cause of Segv.
I briefly look at the #12805 and complexity wise seems quite a bit more elaborate.

I'd say small point fixes (just a if (UNEXPECTED(Z_TYPE_P(zv) != IS_OBJECT)) { check in this case) that add basic guard might be ok, that being said I do appreciate where you are coming from, so I'll leave it to your discretion :-)

I'd say small point fixes (just a if (UNEXPECTED(Z_TYPE_P(zv) != IS_OBJECT)) { check in this case) that add basic guard might be ok, that being said I do appreciate where you are coming from, so I'll leave it to your discretion :-)

IMO it's not worth the hassle, but I don't have any special privileges and won't object if somebody else would like to merge it. If more time is invested, it's probably better to try to finish GH-12805 so that this class of issues is solved completely. There are other similar classes (e.g. __toString(), __destruct, etc.), but the same applies there.