It is now only used to signal exceptions for property reads. ERROR
zvals are never returned back to the VM anymore, so there's no
need to check for them when receiving a VAR.
Also return MAY_BE_ERROR, as ERROR is now no longer relevant for
inference.
Add a max_depth option to unserialize and an unserialize_max_depth
ini setting, which can be used to control the depth limit. The
default value is 4096.
This option is intended to prevent stack overflows during the
unserialization of deeply nested structures.
This fixes bug #78549 and addresses oss-fuzz #17581, #17589, #17664,
and #17788.
* Avoid an unnecessary -lstdc++ dependency. It's not going to be
used in the end anyway, and is an unnecessary hassle to set up.
* Use $LIB_FUZZING_ENGINE instead of hardcoding -lFuzzingEngine.
These variables may not be initialized otherwise, but are passed to
another function; although it seems they are not used there, if not
having been initialized, MSVC complains.
Weirdly these warnings had zero coverage previously...
Remove an incorrect exception checking optimization: The key
lookup may throw (it could also throw previously, though only
through a custom error handler).
rename_variation2.tmp is ... unsurprisingly ... already used by
rename_variation2.phpt. Alternatively it could be placed in the
directory that the test creates, but maybe this is intended to
test cross-directory renames, so I'll leave it.
Resources used as array keys are generally handled by throwing a
notice and converting the resource to the resource handle. The only
exception is the [$resource => null] syntax, where this was treated
as an illegal offset type instead. However, this also only happened
for VM evaluations, the AST evaluator did handle resources correctly.
This also means that we can remove the corresponding special
handling for typed properites: We no longer need to check that a
property is convertible to stdClass if such a conversion might
take place indirectly due to a nested property write.
Additionally OBJ_W style operations now no longer modify the
object operand, and as such we no longer need to treat op1 as a
def in SSA form.
The next step would be to actually compile the whole LHS of OBJ_W
operations in R rather than W mode, but that causes issues with
SimpleXML, whose object handlers depend on the current compilation
structure.
Tyson Andre [Thu, 26 Sep 2019 23:58:34 +0000 (19:58 -0400)]
Update opcache zend_func_info after wbmp/xml_parser changes
See UPGRADING on the master branch.
```
- GD:
. The deprecated function image2wbmp() has been removed.
RFC: https://wiki.php.net/rfc/image2wbmp
. The deprecated functions png2wbmp() and jpeg2wbmp() have been removed.
RFC: https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp
- XML:
. xml_parser_create(_ns) will now return an XmlParser object rather than a
resource.
```
We're getting some very large inputs (~500KB) on OSS-Fuzz, which
slot down performance a lot. Let's try limiting this, starting
with a still fairly large value of 64KB.
Also remove the max_execution_time limit, so that slow test cases
cause a genuine libfuzzer timeout and we may investigate them.
Fix GCOV not working for PHP-7.4 and master branches
Code coverage reports (`make lcov`), since commit eef8522 (7.4 branch),
generates incorrect coverage and emits warnings. Simplifying the
Makefile.gcov file has the side-effect of resolving the issue.
Processing sapi/cli/php_http_parser.gcda
php-src/lcov_data/sapi/cli/php_http_parser.gcda:stamp mismatch with notes file
geninfo: WARNING: gcov did not create any files for php-src/lcov_data/sapi/cli/php_http_parser.gcda!
...
Processing ext/mbstring/mb_gpc.gcda
php-src/lcov_data/ext/mbstring/mb_gpc.gcda:stamp mismatch with notes file
geninfo: WARNING: gcov did not create any files for php-src/lcov_data/ext/mbstring/mb_gpc.gcda!
Closes: https://bugs.php.net/bug.php?id=52718.
See also: https://bugs.php.net/bug.php?id=78288.
`get_closure` handlers are called to check whether an object is
callable, and to actually get the closure, respectively. The behavior
of the handler might differ for these two cases, particularly the
handler may throw in the latter case, but should not in the former.
Therefore we add a `check_only` parameter, to be able to distinguish
the desired purpose.
projects / php / log