Apparently, this has not been tested for a long time, and might be a
refactoring relict. Anyhow, we have to pass the context to
`GIFNextPixel` as well.
Firstly, we must not call `gdImageSetAntiAliased()` (which sets the
color to anti-alias), but rather modify the `gdImage.AA` flag.
Furthermore, we have to actually use the supplied boolean value.
We also make sure that we don't attempt to enable anti-aliasing for
palette images.
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>
`_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#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()`.
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.
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
We must not pass values to `gdImageScale()` which cannot be represented
by an `unsigned int`. Instead we return FALSE, according to what we
already did for negative integers.
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.
* '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.
Christoph M. Becker