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.
- socket_addrinfo_lookup throws when hints is an indexed array.
- socket_get_option hardcoding size outputs to user when data
size known.
close GH-17363
At one point this served a purpose as it contained the cleanup code that
now lives in dtor, but now it just calls the standard handler so we can
just get rid of it.
This is a follow-up on GH-17343 to implement GC cycle management.
Previously the objects lived too long due to the strong cycle.
This patch adds get_gc handlers to break the cycle.
Closes GH-17355.
This is porting the relevant part of a previous upstream commit[1] to
align the behavior of our bundled libgd with upstream. It should be
noted that this only works if the image actually has a transparent
color.
[1] <https://github.com/libgd/libgd/commit/4770e2b2d50c71e60cb073f6bc2e9bc82ec978f7>
Closes GH-17351.
The segfault happens because zoi->wrapping_obj points to an object that has been freed.
This wrapping_obj is set in IntlIterator_from_StringEnumeration().
Notice how the refcount is not increased in this function.
By switching to ZVAL_OBJ_COPY, the segfault disappears.
We also need to move the responsibility of destroying the iterator to
the iterator itself and keep the object data destruction in the object
destruction. The existing code used a weird recursive destruction
between the iterator and object that was too hard to understand to be
honest. This patch simplifies everything and in the process gets rid of
the leak.
Iterators that are embedded are now responsible for their own
memory cleanup.
Closes GH-17343.
This is not a functional change, but rather a performance improvement,
to avoid unnecessary calls of `gdImageSetPixel()` which would be no-ops
due to positions outside of the clipping bounds.
The description of PHP_STRLCPY says that this is a fast version of strlcpy that should be used if we *know* the size of both the source and destination buffers.
This is clearly not the case as we use strlen() to compute it.
Moreover if the result cannot fit in the destination buffer something seriously strange has happened and we should return a failure state rather than truncating.
That bug has been potentially exploitable[1], but the GD extension was
not affected by that, because `gdImageBmpPtr()` is never called. Still
it seems to be reasonable to port the fix; if only to keep bundled and
external libgd synced.
[1] <https://github.com/advisories/GHSA-hc3p-jvff-jfw5>
Christoph M. Becker