[php-src] Issue #10810: Internal exceptions may misinterpret the null byte \0

Issue: https://github.com/php/php-src/issues/10810 Author: b-viguier ### Description The following code: ```php <?php throw new \Exception("Hello\0World"); ``` Resulted in this output: ``` Fatal error: Uncaught Exception: Hello in /tmp/preview:3 Stack trace: #0 {main} thrown in /tmp/preview on line 3 ``` But I expected this output instead: ``` Fatal error: Uncaught Exception: HelloWorld in /tmp/preview:3 Stack trace: #0 {main} thrown in /tmp/preview on line 3 ``` or ``` Fatal error: Uncaught Exception: Hello\x00World in /tmp/preview:3 Stack trace: #0 {main} thrown in /tmp/preview on line 3 ``` ## Notes Thanks to this strange behavior, I discovered that Zend strings are perfectly able to handle the \0 character. But to call the function [zend_throw_exception(zend_class_entry *exception_ce, const char *message, zend_long code)](https://github.com/php/php-src/blob/0d5c794967fa9a1af8d8d96edfbdbbbb97c0f08f/Zend/zend_exceptions.c#L823), some callers may convert a zend string to a raw C string, losing the actual size. Then, the newly created zend string will stop at the first \0, loosing the end of the string. I didn't found any risk with this bug, since sensitive functions seem to look explicitly for this kind of abuse. Just to notice that some error messages may be truncated if they contain this null byte. Here are some other examples: ```php <?php call_user_func("Hello\0World"); $str = "Hello\0World"; new $str; assert(false, "Hello\0World"); ``` :bulb: It may be relevant to prefer the function [zend_throw_exception_zstr](https://github.com/php/php-src/commit/975acfe71ebed352d86753a6deba3475acad3238#diff-8a2e8a28292fef571a73347ef9294bfc6e5026673d8cb417626436922b249d40R823) when possible, to prevent to lose the actual length of the zend string. Thanks for your amazing work :slightly_smiling_face: :+1: ### PHP Version PHP 8.0.28 ### Operating System _No response_