The fix for feature request #53466 did not properly handle resetting of
the corresponding statement; the problem with this is that the
statement does not know about its result sets. But even if we could
fix this, the `complete` handling still appears to be brittle, since
the `sqlite3_column_type()`docs[1] state:
| If the SQL statement does not currently point to a valid row, or if
| the column index is out of range, the result is undefined.
Fortunately, we can use `sqlite3_data_count()` instead, since[2]:
| If prepared statement P does not have results ready to return (via
| calls to the sqlite3_column() family of interfaces) then
| sqlite3_data_count(P) returns 0.
Thus, we guard `SQLite3::columnType()` with `sqlite3_data_count()`, and
completely drop updating the `php_sqlite3_result_object.complete`
field, but keep it for ABI BC purposes.
[1] <https://www.sqlite.org/c3ref/column_blob.html>
[2] <https://www.sqlite.org/c3ref/data_count.html>
It was pointed out on the internals ML[1] that the basename comment
around RFC 1867 file handling was confusing. The comment seemed to
say that the basename handling was only necessary because of some
esoteric bug in Windows IE. In fact that comment applied to earlier
versions of the code and was, therefore, misleading. The comment
needs to clear that basename is required per RFC 7578[2].
[1]:https://externals.io/message/108624
[2]:https://tools.ietf.org/html/rfc7578
At least one segfault observed because temp file creation failed.
Switch to using a memory stream, which should be more robust, and
more efficient for that matter.
exif_process_IFD_TAG() currently accepts a dir_entry, offset_base
and IFDlength. However, it's very hard to follow how these values
are related to each other and the addressable memory region. As we
add additional bounds check, this gets further confused.
One of the basic cases is where dir_entry is in
[offset_base, offset_base+IFDlength), in which case the memory
[dir_entry, offset_base+IFDlength) is valid, but the memory
[offset_base, dir_entry) is not necessarily valid. I wasn't able
to understand what exactly is valid if dir_entry is outside
[offset_base, offset_base+IFDlength)
This patch changes everything to use a struct that separately stores
offset_base and the valid memory region and adds helpers to fetch
offsets and check that pointers are in-bounds.
Closes GH-5068.
As an exception, we allow "Type $foo = null" to occur before a
required parameter, because this pattern was used as a replacement
for nullable types in PHP versions older than 7.1.
Closes GH-5067.
