Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108158
MIME-Version: 1.0
References: <CAMuFt-6=FaqRpTEvZDtW_OsLmq3R171nDc7wH0D5itJUosMtdQ@mail.gmail.com>
 <d2348c4b-7993-489e-86ed-01932a864ec9@www.fastmail.com> <CD056374-BE4F-4B7F-A0F1-5481D024AE8A@newclarity.net>
 <f0a08ad9-abfa-4155-941c-4efd2cf61842@www.fastmail.com> <FF6699B7-39E7-4AD7-8FC6-5EE02BBC8E05@newclarity.net>
 <2502e68d-a1bc-41c6-9763-8c0e2ac9e6f4@www.fastmail.com> <A053F3BB-97CC-4CB3-99DE-275438628E8C@newclarity.net>
 <a599c53d-665b-4e45-9d3e-c5deeac2d5f4@www.fastmail.com> <90DE6E75-813C-4372-A8B7-799ADF74CEDE@newclarity.net>
In-Reply-To: <90DE6E75-813C-4372-A8B7-799ADF74CEDE@newclarity.net>
Date: Wed, 15 Jan 2020 20:58:00 +0000
Message-ID: <CAMuFt-4aut-EiWzBFDghqP+McAiAz=Ly2Qw-b-fAYsSR3qJRzQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Introducing compile time code execution to PHP preloading
From: robehickman@gmail.com (Robert Hickman)

With regards to allowing AST introspection, john blow just posted a
video on JAI which slows why it is useful. Around 11 mins into the
following video he introduces a few lines into the metaprogram (the
thing that interacts with the AST) which essentially 'queries' the
code and reports all occurrences of pointer math. I can think of many
uses for being able to query a program's source like this.

https://www.youtube.com/watch?v=3D0mQbBayzDPI

On Wed, 15 Jan 2020 at 01:57, Mike Schinkel <mike@newclarity.net> wrote:
>
> > On Jan 14, 2020, at 7:50 PM, Larry Garfield <larry@garfieldtech.com> wr=
ote:
> > I think you're still missing my point here.  AST manipulation during pr=
eload would exist to manipulate code that would be run *later*.  That's the=
 point.  Sure, the code in the run_once/preload/whatever block would be wri=
tten to run in that context, but its entire point is, presumably, to improv=
e the running of the *rest* of the code later.
>
> And respectfully, I think I am not missing your point but that possibly y=
ou are misunderstand what I was proposing.
>
> I was not proposing *any* AST manipulation, at least not for what I was d=
efining as "Userland Preloading."   Unless you define AST manipulation as u=
sing PHP to generate code to insert literals into OpCode, but if so I think=
 that would be disingenuous.)
>
> If you remember I said this thread had gotten to the point I am seeing th=
ese separate issues that should probably be three separate threads, which I=
 will repeat here:
>
> 1. Userland preloading
> 2. Userland loadable extensions
> 3. Projection API and related
>
> None of the above manipulate the AST directly, although #3 would do so in=
directly.  (There is an argument to be made that we could split #3 into hig=
her level APIs and lower level AST manipulation which, IMO, should be two d=
ifferent debates, for a total of at least 4 different debates here.)
>
> So again, when I am proposing userland preloading I am *not* as part of t=
hat proposal proposing AST manipulation, although I believe Robert Hickman =
may have been and maybe I should start a different thread?
>
> That is why I find it hard to believe that PHP would generate code that w=
ould fail when PHP runs that code.
>
> > That... is a completely different thing, yes, that has nothing to do wi=
th the PHP 7.4 feature called preloading.  Which would mean we've been talk=
ing about two different things this whole damned time.  *sigh*
>
> Yes.  And I will take the blame for that.  It did not occur to me until R=
obert mentioned to me that it was confusing.
>
> > No, the whole point of the FFI extension is that a user-land developer =
can load a .so file into PHP directly; basically doing the lib->PHP glue co=
de in PHP rather than in C.  It does require the FFI extension itself to be=
 enabled, and to do safely requires using the preloader, which does mean se=
tting an ini setting.
>
> Interesting.  So then maybe what I an asking for is to bundle FFI into co=
re so that it is available everywhere.
>
> > Not all hosts support that.  The one I work for does, which is why I've=
 been playing with it lately to document it all for our customers. :-)  But=
 the fact that such advanced features are not universally available is... e=
xactly why I am extremely cautious about having functionality that results =
in subtle behavioral differences between those environments where it's avai=
lable and those where it's not.
>
> Another interesting option would be to enable loading and running of WebA=
ssembly in core.  Do you have a position on that?
>
> > The existing preload logic has no impact on behavior other than skippin=
g the autoloader.  Any behavioral change is limited to those oddball librar=
ies that do black magic during the autoloader, which are already well off t=
he beaten path.  That makes it a "safe" optimization.
>
> So basically, I think this is what I have been asking for, but userland a=
ccessible.
>
> I would envision that if it modified any environment, such as setting a p=
reloaded or error levels etc. then all that environment would reset during =
normal execution.
>
> > My underlying point, and then I will bow out of this thread as I am tir=
ed of repeating myself, is that I am all for enabling more "safe" optimizat=
ions, even letting userland developers build them, but we need to be extrem=
ely careful about them being "safe" and not "a time bomb that will introduc=
e subtle behavioral differences between different run modes that a develope=
r is not expecting,thus slowly creating libraries that will only function i=
n one run mode or the other".
>
> I appreciate and agree with the desire not to have unsafe issues. But as =
I have felt we were talking about two different things and you confirmed th=
at, maybe what I have actually been proposing is not something we need to b=
e at odds about?
>
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>