* Prevents some unnecessary strlen() computation
* Use interned "NULL"
* Certain PGSQL_API functions now accept zend_string* instead of char*
Closes GH-6792
Firstly, we must not forget to set appropriate error codes for "manual"
checks in `virtual_file_ex()`.
Secondly, we must not call `php_error_docref2()` for warnings regarding
unary functions; thus, we introduce `php_win32_docref1_from_error()`.
Closes GH-6872.
The never type can be used to indicate that a function never
returns, for example because it always unwinds.
RFC: https://wiki.php.net/rfc/noreturn_type
Closes GH-6761.
Paragon Initiative Enterprises is aware of PHP applications that use sodium_compat's ParagonIE\Sodium\Core\XChaCha20 class directly for stream encryption.
Greater performance and security assurance is offered by exposing libsodium's crypto_stream_xchacha20 API to PHP users.
It's acceptable to only include this change in PHP 8.1+; the offending applications are more than welcome to either install ext/sodium from PECL or upgrade to 8.1 when it comes out later this year.
Ref: https://github.com/jedisct1/libsodium-php/pull/211
When we need to enable ASan/UBSan in PHP extension, we also need to enable it in PHP kernel. Providing these options makes it easier for us to enable ASan/UBSan when compiling PHP.
And we use --enable-address-sanitizer and --enable-undefined-sanitizer in azure-pipelines.yml instead of changing CFLAGS manually.
We also add compile flag check to MSan.
The function name should be kept if Closure was created from the function which is marked as ZEND_ACC_CALL_VIA_TRAMPOLINE, because it is not a one-time thing and it may be called multiple times.
Closes GH-6867.
If the script will be cached in SHM (!corrupted), then we cannot
allocate the static variables on the arena. Instead do the same
thing we do during normal persistence and allocate a map ptr slot.
- Treat it as error if multi-byte string or escape sequence is truncated
- Don't allow 'control' characters or escape sequences to appear in the middle
of a multi-byte char
As with ISO-2022-JP-KDDI, the main reference used to develop the tests was
the behavior of the existing code. It would have been better to have some
independent reference which we could cross-check our code against, but I
couldn't find one.
- Treat it as an error if a multi-byte character or escape sequence is truncated
- When converting other encodings to ISO-2022-JP-KDDI, don't swallow trailing
hash characters or digits
- Don't allow 'control' characters to appear in the middle of a multi-byte char
Note: I was not able to find any kind of official or even semi-official
specification for this legacy encoding. Therefore, the test suite for
ISO-2022-JP-KDDI is based largely on the behavior of the existing code.
Verifying the correctness of program code in this way is very questionable.
In a sense, all you are proving is that the code "does what it does". However,
the test suite will still expose any unintended _changes_ to behavior.
