Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124715
Date: Fri, 2 Aug 2024 12:39:20 +0100 (BST)
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
cc: Ilija Tovilo <tovilo.ilija@gmail.com>, 
    PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into
 a standard function
In-Reply-To: <f3c4dcb0-e2e3-424e-94b8-c5a39fcc827c@bastelstu.be>
Message-ID: <9492f9e2-7390-de77-b524-cd84ff452157@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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-843412422-1722598760=:23442"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-843412422-1722598760=:23442
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 3 Jun 2024, Tim D=C3=BCsterhus wrote:

> On 5/29/24 20:05, Derick Rethans wrote:
> >
> > For each op_array, Xdebug tries to figure out every possible path by=20
> > following jumps. Certain opcodes, such as GENERATOR_RETURN, THROW,=20
> > RETURN, and EXIT [1] are considered as an exit point out of the=20
> > function. A path ends there.
>=20
> You linked to a code_coverage.c. Is this information just used for=20
> code coverage analysis to indicate that unreachable code is=20
> unreachable and thus uncoverable or is there more to this?

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=20
that a path (and branch) ends here.

With a function call, I have no idea about whether a path ends there.

> > If there is a function call to a function with a 'never' return=20
> > type, then that function will potentially throw, or exit.
> >=20
> > But that's not relevant for the analysis, as these userland=20
> > functions will have their own oparrays with their entry and exit=20
> > points.
>=20
> The compiler has the function table available. It is used to optimize=20
> specific functions into dedicated Opcodes. Thus you should be able to=20
> look up the function within the function table and then check its=20
> return type.

Yes, but functions that call exit are not required to have the 'never'=20
return type, so that's not useful.

> > > > It also breaks my "do tasks on ZEND_EXIT" with the profiler. It=20
> > > > is used to always write the closing profiling footer to the=20
> > > > files. Without me being able to overload thati opcode, data=20
> > > > would not be complete. I even have two bugs (with tests) for=20
> > > > this:
> > > >=20
> > > > - https://bugs.xdebug.org/68 - https://bugs.xdebug.org/631
> > >=20
> > > Likewise, how is ZEND_EXIT special here? How does it work=20
> > > differently than a script that runs to completion without calling=20
> > > exit(); or a script that fails, e.g. due to an uncaught exception=20
> > > or due to reaching the memory limit?
> >=20
> > I overload EXIT so that I can flush the profile file before the=20
> > script actually fully ends. This is useful for testing through phpt=20
> > tests. It looks like I might be able to use existing function=20
> > observers for this, but I haven't fully made that work yet.
>=20
> Why does the EXIT opcode need to be special-cased here? What if a=20
> script dies due to an uncaught Exception, due to exceeding the memory=20
> limit, or simply terminates by successfully running until the finish,=20
> without explicitly calling exit()?

It's not important for normal functionality as the execution still ends=20
there. It's useful for *testing* as I said before.

>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-843412422-1722598760=:23442--