std_compare_objects immidiately returned 0 if the property tables
of both objects contain NULL at some index. Thus it would report
objects as equal even though properties following after that
differ.
When Wincache or APC are installed, the resource IDs are not the same.
This is because Wincache takes a few resource objects for itself. As a
result, these tests become false positives.
On Windows boxes, the microtime precision is not granular enough
to reliably register a difference if two calls to uniqid() are made
concurrently. This is a fix to the uniqid() test to avoid the false
positive when run on Windows machines. Also, added a test to exercise
the 'more_entropy' variant of uniqid().
Functions registered using zend_register_functions instead of zend_module_entry.functions are not seen on reflection.
Ex: additional_functions from api_module_entry.
Ex: in CLI, dl, cli_set_process_title and cli_get_process_title
Note:
- also affects functions overrided in extension
(should be be reported in extension, where overrided, not in original extension)
- also allow extension to call zend_register_functions for various list
(instead of having a single bug list)
I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yield expression) should first advance to
the first yield and throw the exception there or whether it should
instead throw the exception in the caller's context.
The old behavior was to throw it at the start of the function (i.e.
the very first opcode), which causes issues like the one in #65764.
Effectively it's impossible to properly handle the exceptions in this
case.
For now I choose the variant where the generator advances to the
first yield before throwing, as that's consistent with how all other
methods on the Generator object currently behave. This does not
necessarily match the behavior in other languages, e.g. Python would throw
the exception in the caller's context. But then our send() method already
has this kind of deviation, so it stays internally consistent at least.
In context of static accesses like classname::$this, the string
"$this" should not be handled like a $this variable, but as an
identifier for a static variable.
Also fixes duplicate bugs #54054 and #42098.
Furthermore this fixes incorrect error messages thrown from code
running inside an error handler when a compilation is in progress.
The error file and line are now correctly associated with the
file/line of the executor, rather than the compiler.
Specifically, this checks if there are trait aliases defined in the class scope
before attempting to dereference the first trait alias. This handles the case
where a trait alias was used in a child trait but no aliases exist in the
concrete class.
This fixes bugs #65035 and #65161. In one of the bugs the issue is
that function_state.arguments is NULL, but the arg count is pushed
to the stack and the code tries to free it. In the other bug the
stack of the generator is freed twice, once in generator_close and
later during shutdown.
It's rather hard (if at all possible) to do a proper stack cleanup
on an unclean shutdown, so I'm just disabling it in this case.
nNumOfElements was incremented after the pDestructor code, so any
code in the dtor would get a wrong number of elements.
Right now the bucket deletion code is replicated in four places,
it should probably be moved off into one function (or rather,
zend_hash_apply_deleter should be used everywhere). The codes are
subtly different though in that the HANDLE_UNBLOCK_INTERRUPTIONS()
happens in different places. In particular it seems odd that in
some cases interruptions stay blocked during the destructor call.
Levi Morrison