Hi
On 8/2/24 13:39, Derick Rethans wrote:
It's for that, but also for path/branch analysis, as I just wrote above.
Having an EXIT opcode, instead of a function call is a clean indicator
that a path (and branch) ends here.
With a function call, I have no idea about whether a path ends there.
If the function called the return type `never` then you know that the
path ends there. As the `exit()` function cannot be overridden, you are
even guaranteed that any call to a function called `exit()` is the real
`exit()` function. Either the script exits or the function throws a
TypeError. The latter is true even with current PHP versions as
demonstrated by this example script:
<?php
namespace Foo;
function a() {
exit(new \stdClass());
}
try {
a();
} catch (\Throwable) {}
echo "executed", PHP_EOL;
If there is a function call to a function with a 'never' return
type, then that function will potentially throw, or exit.
But that's not relevant for the analysis, as these userland
functions will have their own oparrays with their entry and exit
points.
The compiler has the function table available. It is used to optimize
specific functions into dedicated Opcodes. Thus you should be able to
look up the function within the function table and then check its
return type.
Yes, but functions that call exit are not required to have the 'never'
return type, so that's not useful.
The `exit()` function as implemented in Gina's PR has the `never` return
type, thus the situation is no worse than the current situation. Instead
of checking for the ZEND_EXIT opcode, you check for a function call and
if the function has the `never` return type (which `exit()` is
guaranteed to have), then you can treat it as a path ending there. Or
you can just hardcode a check for a call to the `exit()` function, as
outlined above.
It also breaks my "do tasks on ZEND_EXIT" with the profiler. It
is used to always write the closing profiling footer to the
files. Without me being able to overload thati opcode, data
would not be complete. I even have two bugs (with tests) for
this:
- https://bugs.xdebug.org/68 - https://bugs.xdebug.org/631
Likewise, how is ZEND_EXIT special here? How does it work
differently than a script that runs to completion without calling
exit(); or a script that fails, e.g. due to an uncaught exception
or due to reaching the memory limit?
I overload EXIT so that I can flush the profile file before the
script actually fully ends. This is useful for testing through phpt
tests. It looks like I might be able to use existing function
observers for this, but I haven't fully made that work yet.
Why does the EXIT opcode need to be special-cased here? What if a
script dies due to an uncaught Exception, due to exceeding the memory
limit, or simply terminates by successfully running until the finish,
without explicitly calling exit()?
It's not important for normal functionality as the execution still ends
there. It's useful for *testing* as I said before.
It was not clear to me that this is only relevant for testing purposes.
I don't understand why you would need the special handling for testing
purposes, but as outlined above you can just hardcode a check for a call
to the `exit()` function if the tests cannot use the regular script end
for some reason.
Best regards
Tim Düsterhus
