(I agree that null should come last, but then it should rather throw with a proper message than emit an undefined key warning.)
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
copy_file_range can return early without copying all the data. This is
legal behaviour and worked properly, unless the mmap fallback was used.
The mmap fallback would read too much data into the destination,
corrupting the destination file. Furthermore, if the mmap fallback would
fail and have to fallback to the regular file copying mechanism, a
similar issue would occur because both maxlen and haveread are modified.
Furthermore, there was a mmap-resource in one of the failure paths of
the mmap fallback code.
This patch fixes these issues. This also adds regression tests using the
new copy_file_range early-return simulation added in the previous
commit.
The UTF-8 valid flag needs to be copied upon interning,
otherwise strings that are concatenated at compile time lose this information.
However, if previously this string was interned without the flag it is not added
E.g. in the case the string is an existing class name.
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>
As an example:
should be translated to:
ZVAL_LONG(&attribute_Attribute_class_test_arg0, ZEND_ATTRIBUTE_TARGET_FUNCTION | ZEND_ATTRIBUTE_TARGET_METHOD);
Previously, notify would only get called on classes with CE_CACHE.
However, during compilation class names are non-permanent which won't
get a CE_CACHE and thus wouldn't not get notified.
Closes GH-9550
This reverts commit 94ee4f9834.
The commit was a bit too late to be included in PHP 8.2 RC1. Given it's a massive ABI break, we decide to postpone the change to PHP 8.3.
Using php_info_print_table_header() for "Foo: bar" looks odd and out of place,
because the whole line is colored. It is also questionable from a HTML
semantics point of view, because it does not described the columns that follow.
The use of this across extensions is inconsistent. It was part of the skeleton,
but ext/date or ext/json already use a regular row.
