Some environments, apparently regardless to the freetype version, output 155, while others 156. I guess we can accept both ;)
This reverts commit 592df89027.
strtok() is not thread safe, so this will potentially break in
very bad ways if used in ZTS mode.
I'm not sure why gd_strtok_r() exists since it seems to do the
same thing as strtok_r(), but I'll assume it's a portability
decision and do as the Romans do.
* PHP-5.5:
Fix bug #67248 (imageaffinematrixget missing check of parameters)
Fix bug #67247 spl_fixedarray_resize integer overflow
fix news
add tests stuff to README
Updated NEWS
Fix Linux specific fail in error traces (cherry-picked and fix for bug #67245) Linux apparently does not like memcpy in overlapping regions...
This amends commit 8f4a537, which aimed to correct NULL dereference because of
missing check of gdImageCreateTrueColor() / gdImageCreate() return value. That
commit checks for negative crop rectangle width and height, but
gdImageCreate*() can also return NULL when width * height overflows. Hence
NULL deref is still possible, as gdImageSaveAlpha() and gdImagePaletteCopy()
is called before dst == NULL check.
This moves NULL check to happen right after gdImageCreate*(). It also removes
width and height check before gdImageCreate*(), as the same check is done by
image create functions (with an extra warning).
From thoger redhat com
Summary:
This caused issues when you picked a font with multiple maps, it wouldn't
pick the unicode version but instead pick the last one it saw. Change so
we cache on a per encoding level. There was even a todo list item in the code.
In an ideal world we can probably iterate through at font write time.
Test Plan:
See said unit test, it's Apache Licensed font included
Initial fix was PHP stuff
This one is libgd fix.
- filter invalid crop size
- dont try to copy on invalid position
- fix crop size when out of src image
- fix possible NULL deref
- fix possible integer overfloow
This fixes GD compilation against libfreetype 2.5.1 and later after they made
the rather interesting decision to change their include directory layout in a
point release.
The original suggestion in the bug was to use pkg-config, but my inclination is
to use freetype-config instead: we should be able to get the same configuration
information without actually needing pkg-config installed, since pkg-config is
by no means guaranteed to exist on many Unices and distros, whereas
freetype-config should always be present if a libfreetype build environment is
installed. Let's try it out and see what happens.
Fixes bug #64405 (Use freetype-config for determining freetype2 dir(s)).
Matteo Beccati