php_stream_read() may return less than the requested amount of bytes by
design. This patch introduces a static function for exif which reads
from the stream in a loop until all the requested bytes are read.
For the test: Co-authored-by: dotpointer
Closes GH-10924.
We only load a minimum set of extensions, and rely on dynamic loading
of others due to `--EXTENSION--` triggers. We do not run the imap,
ldap and snmp test suites, because most of the tests would be skipped
after timeouts anyway.
Closes GH-7150.
This format matches against null bytes, and prevents the test
expectation from being interpreted as binary data.
bless_tests.php will automatically replace \0 with %0 as well.
For rationale, see https://github.com/php/php-src/pull/6787
Make extension checks lowercase, add a special case for opcache
that has internal name not matching .so filename.
Extensions migrated in part 2:
* dom
* exif
* fileinfo
* ffi
Currently we treat paths with null bytes as a TypeError, which is
incorrect, and rather inconsistent, as we treat empty paths as
ValueError. We do this because the error is generated by zpp and
it's easier to always throw TypeError there.
This changes the zpp implementation to throw a TypeError only if
the type is actually wrong and throw ValueError for null bytes.
The error message is also split accordingly, to be more precise.
Closes GH-6094.
The only thing that can promoted are the path-related checked.
Everything else is input dependent and error-suppressing these
functions is both the typical and the recommended usage.
Currently we only ever increment ifd_nesting_level, so this ends up
being a limit on the total number of IFD tags and we regularly get
bug reports of it being exceeded. I think the intention behind this
limit was to prevent recursion stack overflow, and for that we only
need to check actual recursive usage. I've implemented that here,
and dropped the nesting limit down to a smaller value
(which still passes our tests).
However, it seems that we do also need to have a total limit on
the number of tags, as we don't catch some instances of infinite
looping otherwise. Add this as a separate limit with a higher
value, that should hopefully be sufficient.
This is expected to fix a number of bugs:
https://bugs.php.net/bug.php?id=78083https://bugs.php.net/bug.php?id=78701https://bugs.php.net/bug.php?id=79907https://bugs.php.net/bug.php?id=80016
Different manufacturer models may come with a
different endianness (motorola/intel) format. In
order to avoid a big refactor and a gigantic lookup
table, this commit simply attempts to switch the
endianness and proceed when values are acceptable.
Closes GH-5849.
Even if the length of a maker note does not match our expectations
(either because the maker note is corrupted, or because our
expectations do not quite match reality), there is no need to let
parsing fail; we can still go on parsing the other meta information.
var_dump() is debugging functionality, so it should print
floating-point numbers accurately. We do this by switching
to serialize_precision, which (by default) will print with
as much precision as necessary to preserve the exact value
of the float.
This also affects debug_zval_dump().
Closes GH-5172.
* PHP-7.4:
Fix test
Fix bug #78793
Fix build - no model field anymore
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
Fix#78943: mail() may release string with refcount==1 twice
* PHP-7.3:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
Fix#78943: mail() may release string with refcount==1 twice
* PHP-7.2:
Fixed bug #78910Fix#78878: Buffer underflow in bc_shift_addsub
Fix test
Fix#78862: link() silently truncates after a null byte on Windows
Fix#78863: DirectoryIterator class silently truncates after a null byte
Emitting errors is fairly expensive, to the point that parsing
a file with a huge number of invalid tags can take seconds.
Generating ten thousand errors is unlikely to help anybody, but
constitutes a potential DOS vector.
