* PHP-7.4:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
* PHP-7.3:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
* PHP-7.2:
Fix#78876: Long variables cause OOM and temp files are not cleaned
Fix#78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
We must not cast `size_t` to `int` (unless the `size_t` value is
guaranteed to be less than or equal to `INT_MAX`). In this case we can
declare `array_len` as `size_t` in the first place.
In some places, we need to make sure that no warnings are thrown
due to unknown encoding. The error reporting code tried to avoid
this by determining a "safe charset", but this introduces subtle
discrepancies in which charset is picked (normally
internal_encoding takes precedence). Avoid this by suppressing
the warning in the first place.
While here, use the fallback logic to print error messages with
substitution characters more consistently, to avoid skipping
parts of the error message entirely.
Treatment of locales in PHP is currently inconsistent: The LC_ALL
locale is set to "C", as is standard behavior on program startup.
The LC_CTYPE locale is set to "", which will inherit it from the
environment. However, the inherited LC_CTYPE locale will only be
used in some cases, while in other cases it is necessary to perform
an explicit setlocale() call in PHP first. This is the case for
the locale-sensitive handling in the PCRE extension.
Make things consistent by *never* inheriting any locales from the
environment. LC_ALL, including LC_CTYPE will be "C" on startup.
A locale can be set or inherited through an explicit setlocale()
call, at which point the behavior will be fully consistent and
predictable.
Closes GH-5488.
Even if default_charset is set to "", we should still return
"UTF-8" as the default value here. Setting default_charset to ""
suppresses the header emission, but shouldn't change anything
about our encoding defaults.
This is actually about three distinct issues:
* If an empty string is passed as $address to `stream_socket_sendto()`,
the `sa` is not initialized, so we must not pass it as `addr` to
`php_stream_xport_sendto()`.
* On POSIX, `recvfrom()` truncates messages which are too long to fit
into the specified buffer (unless `MSG_PEEK` is given), discards the
excessive bytes, and returns the buffer length. On Windows, the same
happens, but `recvfrom()` returns `SOCKET_ERROR` with the error code
`WSAEMSGSIZE`. We have to catch this for best POSIX compatibility.
* In `php_network_parse_network_address_with_port()`, we have to zero
`in6` (not only its alias `sa`) to properly support IPv6.
Co-Authored-By: Nikita Popov <nikita.ppv@googlemail.com>
php_mergesort() isn't being used for anything, and hasn't been for
a long time. Even if we wanted to use a stable sort, this isn't
the implementation we'd use...
It was pointed out on the internals ML[1] that the basename comment
around RFC 1867 file handling was confusing. The comment seemed to
say that the basename handling was only necessary because of some
esoteric bug in Windows IE. In fact that comment applied to earlier
versions of the code and was, therefore, misleading. The comment
needs to clear that basename is required per RFC 7578[2].
[1]:https://externals.io/message/108624
[2]:https://tools.ietf.org/html/rfc7578
To be able to see changes done only with `SetEnvironmentVariable()`, we
have to use `GetEnvironmentStrings()` instead of `environ`, because the
latter sees only changes done with `putenv()`.
For best backward compatibility we're using `GetEnvironmentStringsA()`;
switching to the wide string version likely makes sense for master,
though.
