Since upstream does not appear to move in any way[1], we sync our
behavior. Even though the BC break is ugly (which is the reason we
target master only), having to deal with different algorithms is even
worse for portable userland code.
[1] <https://github.com/libgd/libgd/issues/334>
Since cropping support has been added to our bundled libgd,
`gdImageAutoCrop` differs from upstream in that `GD_CROP_DEFAULT` falls
back on `GD_CROP_SIDES` if there is no transparent color in the image.
While this difference seem to be a useful improvement in our bundled
libgd, upstream has not yet signaled that there willing to back-port
it[1], so we revert it to stay in sync with upstream.
We also remove the additional NULL bailout at the end of the function,
which doesn't appear to be relevant any longer since bug 77198 has been
fixed.
[1] <https://github.com/libgd/libgd/issues/298>
We apply the upstream patch[1], and also fix the erroneous bailout at
the end of `gdImageAutoCrop()`, since `crop.x` and `crop.y` may very
well be zero.
[1] <bda85aaeeb>
The broken JPEG image triggers a notice, two warnings and outputs a
message to stderr directly. The additional notice is pretty useless,
and the direct output to stderr is bad. Therefore, we port the
relevant differences from upstream to our bundled libgd. This leaves
us with two warnings; the first one is triggered by libjpeg and shows
the actual problem, the second one is triggered by our libgd wrapper
whenever an image can't be read, what may not have necessarily
triggered a warning before.
We must not draw anti-aliased lines on palette images, because that is
not supported by `gdImageSetAAPixelColor()` and it wouldn't make much
sense to support it, due to the limitation to at most 256 colors.
Besides that we still hope to sync the complete bundled libgd sometime,
the upstream implementation of `gdImageCrop()` is much simpler than the
current one, and thus better readable and less error prone.
* 'master' of git.php.net:/php-src:
Update NEWS
Fixed bug #75571: Potential infinite loop in gdImageCreateFromGifCtx
Fix bug #74782: remove file name from output to avoid XSS
* 'PHP-7.2' of git.php.net:/php-src:
Update NEWS
Fixed bug #75571: Potential infinite loop in gdImageCreateFromGifCtx
Fix bug #74782: remove file name from output to avoid XSS
* 'PHP-7.1' of git.php.net:/php-src:
Update NEWS
Fixed bug #75571: Potential infinite loop in gdImageCreateFromGifCtx
Fix bug #74782: remove file name from output to avoid XSS
Due to a signedness confusion in `GetCode_` a corrupt GIF file can
trigger an infinite loop. Furthermore we make sure that a GIF without
any palette entries is treated as invalid *after* open palette entries
have been removed.
We apply the respective patches from external libgd, work around the
still missing `gdImageClone()`, and fix the special cased rotation
routines according to Pierre's patch
(https://gist.github.com/pierrejoye/59d72385ed1888cf8894a7ed437235ae).
We also cater to bug73272.phpt whose result obviously changes a bit.
We back-port dd48286 even though
we cannot come up with a regression test, because the erroneous
condition appears to be impossible to trigger.
We also parenthesize the inner ternary operation to avoid confusion.
We have to make sure to avoid alpha-blending issues by explicitly
switching to `gdEffectReplace` and to restore the old value afterwards.
This is a port of <a7a7ece>.
Crafted BMP images can cause dynamicSeek() to be called with a negative
position which must not be allowed, since dynamicSeek() works like
fseek() in SEEK_SET mode. We solve this by bailing out if `pos` is
negative, and let the image reading fail gracefully.
