Before this patch, exif_process_IFD_in_MAKERNOTE() would return false, then causing the rest of the EXIF parsing to be interrupted. This is a regression from earlier which was most likely a part of a security fix for MAKERNOTE.
The new behavior is to instead of stopping to parse, to continue so we can still fetch data like thumbnail and GPS, thrus allowing yet unsupported formats to parse. If EXIF's debugging mode is enabled, a notice will display in case we do not match against a valid MAKERNOTE signature.
This should temporarily fix bug #72682 (exif_read_data() fails to read all data for some images) until I get around to debug it further.
(cherry picked from commit aabcb5481d)
Calling imagesetstyle() with an empty $styles array caused gdImageSetStyle()
to be called with `noOfPixels==0`, what could have lead to OOB reads.
Actually, this issue will be fixed in libgd, but to avoid issues when older
libgd is in use, we simply disallow passing an empty $styles array to
imagesetstyle(), what wouldn't serve a useful purpose anyway.
This reverts commit 14d674442e.
I misread the discussion on the bug -- this is not the correct
fix. However the other proposed fix does not work either, so just
reverting for now.
Julian days < 347998 denote invalid Jewish calendar dates, so
cal_from_jd($jd, CAL_JEWISH) and jdmonthname($jd, CAL_MONTH_JEWISH) should
actually fail. For BC we don't yet let them though, but we fix the OOB read
that happens in this case, and we also adjust cal_from_jd()'s return value
to have empty strings for "abbrevdayname" and "dayname" instead of "Sun"/
"Sunday" and NULL for "dow" instead of 0, which doesn't make any sense.
From the [sqlite3_open](https://www.sqlite.org/c3ref/open.html) docs:
| If the filename is an empty string, then a private, temporary on-disk
| database will be created. This private database will be automatically
| deleted as soon as the database connection is closed.
We make that facility available to userland.
While we're at it, we also do some minor optimizations, remove the
unnecessary check for NUL characters in filename, which is already catered
to by ZPP(p), and add a missing `return` in case db_obj isn't initialized.
Open data stream after receiving PASV reply, before sending the
main request.
Included test cases for opendir() with ftp:// and ftps:// wrappers.
Test cases re-use ext/ftp/tests/server.inc
Conflicts:
ext/standard/ftp_fopen_wrapper.c
The test claims that it would be "checking all the values in returned array",
but due to the use of %a it actually skipped elements. We fix that by using
%s instead.
No pixel of a filled arc must ever be drawn multiple times. Otherwise we get
artifacts regarding transparency. That happens with the current
implementation of gdImageFilledArc() unless gdChord or gdNoFill are set.
When gdPie is set, however, the filled arc is drawn in wedges, which are
polygons of three points, and so some overlap is natural.
To resolve the issue, we stick with the current algorithm of calculating the
wedges, but instead of drawing each polygon separately, we put the relevant
points in a large array, and draw a single polygon. That also is supposed to
improve the performance considerably.
Note that this modification will change the results when gdImageSetStyle()
or gdImageSetBrush() are used, but we believe that this modification is also
an improvement in this regard, even though it still might not make much
sense to use these functions with gdImageFilledArc().
The respective fix for libgd is
<https://github.com/libgd/libgd/commit/e7e20d6>.
The test images for #72603 and #72618 are broken, that seems to be
the cause of different test output. Seems also to be platform dependent,
so it's not reliable to depend on the exact error output.
