This patch removes the so called local variables defined per
file basis for certain editors to properly show tab width, and
similar settings. These are mainly used by Vim and Emacs editors
yet with recent changes the once working definitions don't work
anymore in Vim without custom plugins or additional configuration.
Neither are these settings synced across the PHP code base.
A simpler and better approach is EditorConfig and fixing code
using some code style fixing tools in the future instead.
This patch also removes the so called modelines for Vim. Modelines
allow Vim editor specifically to set some editor configuration such as
syntax highlighting, indentation style and tab width to be set in the
first line or the last 5 lines per file basis. Since the php test
files have syntax highlighting already set in most editors properly and
EditorConfig takes care of the indentation settings, this patch removes
these as well for the Vim 6.0 and newer versions.
With the removal of local variables for certain editors such as
Emacs and Vim, the footer is also probably not needed anymore when
creating extensions using ext_skel.php script.
Additionally, Vim modelines for setting php syntax and some editor
settings has been removed from some *.phpt files. All these are
mostly not relevant for phpt files neither work properly in the
middle of the file.
Even though libgd/libgd#492 is not a relevant bug fix for PHP, since
the binding doesn't use the `gdImage*Ptr()` functions at all, we're
porting the fix to stay in sync here.
The fix for PHP bug 43828[1] changed the algorithm from drawing filled
pies from drawing multiple triangles to drawing a single polygon. Due
to quirks of the filled polygon drawing algorithm, we had to filter out
extraneous vertices. This lead, however, to a bug regarding displaced
starting and ending points near 90° and 270° degrees, which we fix by
reinserting these vertices if they had been removed.
This fix is a port of libgd/libgd@1406b1a.
[1] <https://bugs.php.net/bug.php?id=43828>
* --with-webp-dir becomes --with-webp
* --with-jpeg-dir becomes --with-jpeg
* --with-png-dir is removed. libpng is required.
* --with-zlib-dir is removed. zlib is required.
* --with-xpm-dir becomes --with-xpm.
We also enable --with-webp on Travis.
`_gdScaleHoriz()` and `_gdScaleVert()` may fail, but don't signal
failure since they are void functions. We change that according to
upstream libgd.
We also remove the unused `Scale()` function, which doesn't exist in
upstream libgd either, right away.
* PHP-7.3:
Fix#77367: Negative size parameter in mb_split
Fix#77369 - memcpy with negative length via crafted DNS response
Fix more issues with encodilng length
Fix#77270: imagecolormatch Out Of Bounds Write on Heap
Fix bug #77380 (Global out of bounds read in xmlrpc base64 code)
Fix bug #77371 (heap buffer overflow in mb regex functions - compile_string_node)
Fix bug #77370 - check that we do not read past buffer end when parsing multibytes
Fix#77269: Potential unsigned underflow in gdImageScale
Fix bug #77247 (heap buffer overflow in phar_detect_phar_fname_ext)
Fix bug #77242 (heap out of bounds read in xmlrpc_decode())
Regenerate certs for openssl tests
* PHP-7.2:
Fix#77369 - memcpy with negative length via crafted DNS response
Fix more issues with encodilng length
Fix#77270: imagecolormatch Out Of Bounds Write on Heap
Fix bug #77380 (Global out of bounds read in xmlrpc base64 code)
Fix bug #77371 (heap buffer overflow in mb regex functions - compile_string_node)
Fix bug #77370 - check that we do not read past buffer end when parsing multibytes
Fix#77269: Potential unsigned underflow in gdImageScale
Fix bug #77247 (heap buffer overflow in phar_detect_phar_fname_ext)
Fix bug #77242 (heap out of bounds read in xmlrpc_decode())
Regenerate certs for openssl tests
* PHP-7.1:
Fix#77369 - memcpy with negative length via crafted DNS response
Fix more issues with encodilng length
Fix#77270: imagecolormatch Out Of Bounds Write on Heap
Fix bug #77380 (Global out of bounds read in xmlrpc base64 code)
Fix bug #77371 (heap buffer overflow in mb regex functions - compile_string_node)
Fix bug #77370 - check that we do not read past buffer end when parsing multibytes
Fix#77269: Potential unsigned underflow in gdImageScale
Fix bug #77247 (heap buffer overflow in phar_detect_phar_fname_ext)
Fix bug #77242 (heap out of bounds read in xmlrpc_decode())
Regenerate certs for openssl tests
At least some of the image reading functions may return images which
use color indexes greater than or equal to im->colorsTotal. We cater
to this by always using a buffer size which is sufficient for
`gdMaxColors` in `gdImageColorMatch()`.
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.
