Christoph M. Becker

Indeed, this is due to the overloaded `uopz_set_return()`: https://github.com/krakjoe/uopz/blob/6db6be8d646296d10bfab641cd9d283a6909a51f/uopz.c#L199-L200 If the first ZPP fails, `clazz` might be assigned, but is not changed afterwards. That looks like a bug to me....

That! As of PHP 8.0.0, `curl_close()` is a no-op; that is already documented. The closest pendant as of PHP 8.0.0 is to destroy the object. Maybe we should clarify this...

> Maybe `curl_close` should be deprecated? There is no reason to keep it around and it's not the first time I've seen confusion about `curl_close`. FWIW before 8.0 `unset($ch)` had...

Does it also crash, if you disable Xdebug altogether?

There is no special treatment for BOMs; instead these are just treated as arbitrary characters would, and since a field starting with arbitrary characters followed by a pair of double-quotes...

@Girgias, any thoughts on BOMs in CSV files? How are these handled by PECL/csv?

> I just tried on PECL/csv and the behaviour currently is: Would you get the same result for some arbitrary bytes instead of a BOM?

I just found https://bugs.php.net/49350 and https://bugs.php.net/63433, and both have been closed as not-a-bug.

> There is a comment in the documentation talking about this behaviour and how to handle the case. Maybe we should just document it more officially ? Yeah, I noticed...

It is parsed as float, though: https://github.com/Imagick/imagick/blob/661405abe21d12003207bc8eb0963fafc2c02ee4/imagick_class.c#L5526 The stub/arginfo parameters are only relevant for reflection, in debug builds (a double-check happens there), and for inheritance (and for the documentation, if...