- When building with bundled libgd, it has support for BMP
- When building with external libgd, at least 2.1.0 is required, which
has BMP support.
- The HAVE_GD_PNG moved to PHP_GD_PNG Autoconf macro as it is always
required when building with bundled libgd.
When global constants' or class constants' availability is based on some
preprocessor condition, the generated arginfo header files wrap the
declarations in the preprocessor `#if` conditional blocks, one per declaration,
even if they are in the same conditional block based on comments in the stub
file. Instead of having multiple conditional blocks one after the other with
the same condition, combine them into a single conditional block.
This is in preparation for the possible future transformation of `clone` into a
function call, but also meaningful on its own, since the purpose of the tests
is not to test the stack trace generation, but rather that an exception was
thrown. It also cleans up some unreachable code in the tests.
```
ext/gd/libgd/gd.c:2275:14: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
#0 0x5d6a2103e1db in php_gd_gdImageCopy /home/dcarlier/Contribs/php-src/ext/gd/libgd/gd.c:2275
#1 0x5d6a210a2b63 in gdImageCrop /home/dcarlier/Contribs/php-src/ext/gd/libgd/gd_crop.c:57
#2 0x5d6a21018ca4 in zif_imagecrop /home/dcarlier/Contribs/php-src/ext/gd/gd.c:3575
#3 0x5d6a21e46e7a in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1337
#4 0x5d6a221188da in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:57246
#5 0x5d6a221366bd in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:61634
#6 0x5d6a21d107a6 in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1895
#7 0x5d6a21a63409 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2529
#8 0x5d6a22516d5e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:966
#9 0x5d6a2251981d in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1341
#10 0x7f10d002a3b7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7f10d002a47a in __libc_start_main_impl ../csu/libc-start.c:360
#12 0x5d6a20a06da4 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2806da4) (BuildId: d9a79c7e0e4872311439d7313cb3a81fe04190a2)
```
close GH-18006
skip if imagefttext() is not available
This test calls imagefttext(), which may not be available if libgd
was built without freetype support.
Closes GH-17910
- Three of our gd tests could be skipped with a message about requiring
bundled GD, but those tests don't actually require bundled GD. We
update the messages to mention the specific functions that are
required.
- add SKIPIF stanzas for missing PNG support
The bundled libgd always has PNG support, but an external one may not.
- imagerotate() is always available
Following 59ec80c5, the imagerotate() function is always available. We
may therefore remove its function_exists() checks without harm.
close GH-17894
These warnings are about conversion from `size_t` to a smaller type[1],
and in this case because `gdIOCtx` works with `int` lengths. Two of
these warnings are harmless, and we resolve them by using `size_t` in
the first place, and adding a cast (plus an assertion), respectively.
The others actually hint at potential issues when reading image data
with more than `INT_MAX` bytes; we catch that upfront, and throw a
`ValueError` and a warning, respectively.
[1] <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4267>
* 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] <https://github.com/libgd/libgd/commit/2a921c80fbdd1d684f32bf763c26e024052314e6>
Closes GH-17366.
This improvement was done for libgd 2.1.0[1], and the erroneous
calculation has been fixed as of libgd 2.2.0[2].
While we're at it we also add the overflow checks of external libgd;
these are not really necessary, since `.sx * .sy` overflow was already
prevented when the image has been created, and since we're using
`safe_emalloc()` the `struct seg` overflow is also prevented. It
should be noted that `overflow2()` prevents `int` overflow, while
`safe_emalloc()` prevents `size_t` overflow, so the former is more
restrictive. For parity with external libgd, this still appears to be
a good thing.
[1] <https://github.com/libgd/libgd/commit/86a5debede97ded92d644c3e06964c299e1e0810>
[2] <https://github.com/libgd/libgd/commit/e87ec88e1c4db664baf2c42e7fccf3f9dc53f0a6>
We apply the same fix that has been applied to external libgd at least
as of 2.0.29.
To avoid issues regarding minor FreeType rendering differences, the
test case does not compare against an image, but rather checks that all
pixels outside the clipping rect have the background color.
Closes GH-17374.
Peter Kokot