This reverts commit 6305119a51.
This is a source-compatibility break for extensions that define
custom FastZPP macros, such as ext/uv:
a983eb17b6/php_uv.c (L75)
I don't think that FastZPP was intended to be used this way, but
let's revert this from release branches to avoid extension breakage.
This is useful for coverage. While it is currently safe to just
skip over the SWITCH_* opcodes, this may not be true in the future
due to opcache optimizations, so it's safer to disable emission of
SWITCH_* opcodes entirely.
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>
In f904830012, support for GNU Hurd was added to the opcache and
the configure check to ensure the opcache knows the flock struct
layout prior to building was changed check for two cases: BSD layout
and Linux layout. All the existing hard-coded cases in
ZendAccelerator.h follow these two cases, except for 64-bit AIX.
This means that even though building on 64-bit AIX would work,
the configure script refuses to continue.
Add a new configure check for the 64-bit AIX case and a new
compiler definition HAVE_FLOCK_AIX64. Now that all the cases are
covered, simplify the ifdef logic around these three HAVE_FLOCK_*
macros:
- The macOS and the various BSD flavors fall under HAVE_FLOCK_BSD
- Linux, HP-UX, GNU Hurd, 32-bit AIX, and SVR4 environments
fall under HAVE_FLOCK_LINUX
- 64-bit AIX falls under HAVE_FLOCK_AIX64
The only difference between the existing HAVE_FLOCK_LINUX and
the hard-coded Linux/HP-UX/Hurd case is that the latter
initialized the 5th member to 0, but since the C standard already
says that un-initialized members will be initialized to 0,
it's effectively the same.
The idea is to create an easy way to provide a certificate that never
expires. In order to make it cross-platform, PHP is used rather than
openssl CLI app. Using openssl to generate certificates for tests that
test openssl might be not the best idea but pros seem to outweight cons
that this "recursice dependency" adds
`_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.1:
Fix bug #77418 - Heap overflow in utf32be_mbc_to_code
Add NEWS
[ci skip] Add NEWS
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-5.6:
Fix bug #77418 - Heap overflow in utf32be_mbc_to_code
[ci skip] Add NEWS
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()`.
