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>
Even though `SplStack::unserialize()` is not supposed to be called on
an already constructed instance, it is probably better if the method
clears the stack before actually unserializing.
Unfortunately, some Webservers (e.g. IIS) do not implement the (F)CGI
specifications correctly wrt. chunked uploads (i.e. Transfer-encoding:
chunked), but instead pass -1 as CONTENT_LENGTH to the CGI
application. However, our (F)CFI SAPIs (i.e. cgi and cgi-fcgi) do not
support this.
Therefore we try to retrieve the stream size in advance and pass it to
`curl_mime_data_cb()` to prevent libcurl from doing chunked uploads.
This is basically the same approach that `curl_mime_filedata()`
implements, except that we are keeping already opened streams open for
the `read_cb()`.
Some commits missed to update the patch file, so we're catching up on
this.
To generally make this easier, we back-port generate_patch.sh from
PHP-7.4, where we now also generate magic.h from magic.h.in.
We have to free the `ansiname`s, regardless of whether they have been
put into the hashtable or not.
Since bug79299.phpt already shows the leak when run with a leak
checker, there is no need for another regression test.
Releasing the `com_dotnet_istream_wrapper` in `istream_destructor()` is
pointless, since `istream_destructor()` is only called when the
resource is going to be released. This recursion is not a real issue,
though, since the resource is never exposed to userland, and has at
most refcount 1, so due to well defined unsigned integer underflow, it
never is released twice. However, returning early in this case causes
a memory leak which needs to be fixed.
