Closes GH-8830
MAP_FIXED guarantees mmap will return that exact address or fail so the
address comparison is redundant.
The return value of this function is unused but I kept it because it
improves readability.
Fix GH-8756 : oci_new_descriptor() triggers dynamic property
deprecation.
This fix should be temporary. At some point we should either define
those properties or just hide them since they should probably not be
used.
Better fix is here : https://github.com/php/php-src/pull/8758 but
waiting feedback from Oracle team before going ahead.
We fix the `UNEXPECTED(EXPECTED(…))`, which does not make sense, and
replace the magic number with the respective macro. We also add a
test case to verify the expected behavior for an `array_fill()` edge
case.
Closes GH-8804.
We revert the commits which caused this regression from the PHP-8.0 and
PHP-8.1 branches for now. We keep it in "master" because of PR #8833
which may offer a proper fix without BC break.
Nothing new but to refactor usage b/w hash and password
extensions but using volatile pointers to be a bit safer,
allowing to expand its usage eventually.
The new Linux 5.17 feature PR_SET_VMA_ANON_NAME can give names to
anonymous private memory, see:
https://lwn.net/Articles/867818/
It can be useful while debugging, to identify which portion of the
process's memory belongs to which subsystem.
This is how /proc/PID/maps can look like:
555ccd400000-555ccdc00000 r-xp 00000000 00:00 0 [anon:huge_code_pages]
7f6ec6600000-7f6ec6800000 rw-p 00000000 00:00 0 [anon:zend_alloc]
The first mapping is the PHP executable copied to anonymous memory by
option "opcache.huge_code_pages". The second one is a memory area for
the "zend_alloc.h" memory allocator library.
Unfortunately, it is not possible to give names to shared memory
(MAP_SHARED), because Linux MAP_SHARED really maps /dev/zero (see
shmem_zero_setup()), which makes madvise_vma_anon_name() believe this
is a file mapping, failing the prctl() with EBADF.
If there is a zero timeout and MSG_DONTWAIT is available (or the
socket is non-blocking), the poll() call is not necessary, and we can
just call recv() right away.
Before this change:
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=4, revents=POLLIN}])
recvfrom(4, "HTTP/1.1 301 Moved Permanently\r\n"..., 8192, MSG_DONTWAIT, NULL, NULL) = 348
poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1 ([{fd=4, revents=POLLIN}])
recvfrom(4, "", 1, MSG_PEEK, NULL, NULL) = 0
After this change:
recvfrom(4, 0x7ffe0cc719a0, 1, MSG_PEEK|MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=4, revents=POLLIN}])
recvfrom(4, "HTTP/1.1 301 Moved Permanently\r\n"..., 8192, MSG_DONTWAIT, NULL, NULL) = 348
recvfrom(4, "", 1, MSG_PEEK|MSG_DONTWAIT, NULL, NULL) = 0
The first poll() is replaced by recvfrom(), and the third poll() is
omitted completely.
ext/openssl/xp_ssl: eliminate poll() when MSG_DONTWAIT is available
If there is a zero timeout and MSG_DONTWAIT is available (or the
socket is non-blocking), the poll() call is not necessary, and we can
just call recv() right away.
Closes GH-8092.
When casting a `variant` to `int`, we need to heed the proper `zval`
type, which is an signed 64bit integer on x64, while `VT_INT` is only
a signed 32bit integer.
Closes GH-8779.
In 8b3c1a3, this was disallowed to fix#55856, which was a security
issue caused by the /e modifier. The fix that was made was the
"Easier fix" as described in the original report.
With this fix, pattern strings are no longer treated as null terminated,
so null characters can be placed inside and matched against with regex
patterns without security problems, so there is no longer a reason to
give the error. Allowing this is consistent with the behaviour of many
other languages, including JavaScript, and thanks to PCRE2[0], it does
not require manually escaping null characters. Now that we can avoid the
error here without the cost of escaping characters, there is really no
need anymore to stray here from the conventional behaviour.
Currently, null characters are still disallowed before the first
delimiter and in the options section at the end of a regex string, but
these error messages have been updated.
[0] Since PCRE2, pattern strings no longer have to be null terminated,
and raw null characters match as normal.
Closes GH-8114.
George Peter Banyard