Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124780
Message-ID: <5943ce1d-fd0d-4efa-be7e-a2df456253b1@bastelstu.be>
Date: Mon, 5 Aug 2024 19:03:03 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a
 standard function
To: Derick Rethans <derick@php.net>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
 <b2IQjZQlOsMoMuk9Jw5edeVfHqqbcWCQc6DQF5jKrRkGryVyvu6rC9sbSW2D-HK9jH2QUmkoIy--aQROFsx-3QPr8CjIfltTnhbZYGxsixI=@gpb.moe>
 <CAPyj-LBpmYv30JFW3x-ZL=28vivrh7d04L97rbXeYxDJirwKCg@mail.gmail.com>
 <ca1189e2-4bb7-3008-4b52-694cd14aed8d@php.net>
 <9c69992e-2962-476d-baca-aa51bdd0f1f7@bastelstu.be>
 <67f2f610-dca8-e8ce-a513-2aef0fcf2698@php.net>
 <f3c4dcb0-e2e3-424e-94b8-c5a39fcc827c@bastelstu.be>
 <9492f9e2-7390-de77-b524-cd84ff452157@php.net>
Content-Language: en-US
In-Reply-To: <9492f9e2-7390-de77-b524-cd84ff452157@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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