The whole point of using `proc_open()` to execute `openssl s_client` is
that we can terminate the process when we're done. However, when going
through the shell on Windows, we get a handle to the shell process, and
if we terminate that, the grandchild will stay open. Since the pipes
of the grandchild will stay open, the PHP process will not terminate
either, so the test stalls.
We solve this by simply bypassing the shell.
* Drop superfluous php_com_dotnet_object.ce
This is readily available via the `zend_object` (i.e. `zo.ce`), so
there is no need to duplicate it.
There is also no need to assign the ce to the std object,
since this is done be `zend_object_std_init()` anyway.
As explained by Snape3058: On 64-bit machines, we typically have 7 bytes
of padding between the zend_string.val[0] char and the following char[].
This means that zend_string.val[1-7] write to and read from the struct
padding, which is a bad idea.
Allocate the given string separately instead.
Fixes GH-17564
Closes GH-17576
Only (dtd) named node maps should have string-based indexing.
The ce check is fragile, just check for the presence of an xml hash
table.
Closes GH-17580.
* Use type declarations instead of doc-block annotations
* Inline the terrible get_rgb() function
* Always traverse pixels in Z order
libgd stores the pixel as an array of rows, so we should use row-major-
order traversal to improve caching.
* Add assertions to avoid misuse of the functions
The assertion regarding the image dimensions won't break any tests, and
we had it already as a comment.
However, asserting that the images are truecolor images is important
for `calc_image_dissimilarity()` which otherwise would calculate
nonsense, and not unreasonable for `test_image_equals_image()` which
otherwise is overspecified (for our purposes, it doesn't matter which
palette entry a pixel refers to, but rather whether the actual colors
referred by a palette color match).
Since the truecolor assertions break two tests, we fix these by
converting to truecolor. That should likely be backported to lower
branches.
* Drop implicit conversion to truecolor
Conversion to truecolor is a relatively expensive operation, and as
such should not be implicit; instead test authors are encouraged to use
truecolor images in the first place where possible, or to even find
better ways to verify expectations than doing a full image comparison.
* Merge similarity.inc into func.inc
There is no particular reason to have a separate file for similarity
comparisons.
* Simplify bug43475.phpt and bug64641.phpt
`calc_image_dissimilarity()` calculates the sum of the euclidean
distance of the RGB channels of all pixels. The euclidean distance is
either zero or greater than or equal to one (but never in ]0, 1[). The
sum of these values also has this property, so it doesn't make sense to
check for less than 1e-5. Thus we just call `test_image_equals_file()`
instead.
* Replace calc_image_dissimilarity() with the well-known mse()
`calc_image_dissimilarity()` has the drawback that it did sum up the
pixel differences, so for large images the result could be way larger
than for small images. It also has the drawback that it likely is not
as well understood as the mean squared error. Thus we replace it with
the latter, and calculate the mean squared error of the individual RGB
channels (to be precise). The result is always in range 0..255**2 what
makes reasoning about thresholds easier.
First, the `$fontfile` parameter actually supports a semicolon
delimited list of fonts (as documented[1]); thus passing the full
string to `VCWD_REALPATH()` or `php_check_open_basedir()` makes no
sense; we could pass the individual parts, but …
Second, libgd uses an elaborate font detection. There is a hard-
coded `DEFAULT_PATH` which can be overridden by the environment
variable `GDFONTPATH`. Semantics are like the `PATH` environment
variable. If `DEFAULT_PATH` was still exposed (it is no longer as of
libgd 2.1.0[2]), we could take that into account, but …
External libgd can be configured with font-config support, so font
aliases and even lookup patterns are supported. There is no way to
cater to that upfront.
Thus, we no longer interfere with libgd's font lookup. Checking the
realpath was already doubtful (we didn't even use the resolved path).
Lifting the open_basedir restriction is a bit more delicate, but the
manual still states that open_basedir would not apply, and more
relevant, not much harm can be done, because libgd only passes the
found font to `FT_New_Face()` which likely fails for any non font files
without any error which could reveal sensitive information. And the
font file is never written.
It should be noted that this solves lookup of system fonts, does not
change the behavior for absolute font paths, but still does not resolve
issues with relative paths to font files in ZTS environments using
external libgd (our bundled libgd has a workaround for that). This
particular issue cannot be solved, so users of ZTS builds still need to
add `realpath(.)` to the `GDFONTPATH` as documented in the manual (or
pass absolute paths as `$fontfile`).
[1] <https://www.php.net/imagettftext>
[2] <2a921c80fb>
Closes GH-17366.
If both the driver object and statement end up in the GC buffer and are
freed by the GC, then the destruction order is not deterministic and it
is possible that the driver object is freed before the statement. In
that case, accessing S->H will cause a UAF. As the resources are already
released we simply skip the destruction if the driver object is already
destroyed.
