Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107269
MIME-Version: 1.0
References: <abaecc58-37bc-03cd-51a7-c32b12b03bf5@gmail.com>
In-Reply-To: <abaecc58-37bc-03cd-51a7-c32b12b03bf5@gmail.com>
Reply-To: bishop@php.net
Date: Fri, 20 Sep 2019 12:10:05 -0400
Message-ID: <CAEYWF=70hrKN6Fc0dSJwHV_0KmFm46qkcXq2Mz=3O5ePtdmPJw@mail.gmail.com>
To: Henrik Skov <henry.wood.dk@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000027f3250592fe4f7d"
Subject: Re: [PHP-DEV] PHP 7 + bcgen extension + PHAR extension
From: bishop@php.net (Bishop Bettini)

--00000000000027f3250592fe4f7d
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 4, 2019 at 8:44 AM Henrik Skov <henry.wood.dk@gmail.com> wrote:

> I found a port of bcompiler here:
>
> https://github.com/vjardin/bcgen/
>
> which is PHP7 compatible.
>
> By mailing here, I am trying to reach out to the authors of the PHAR
> extension since the author(s) of bcgen have said that they don't know
> enough about the PHAR extension.
>

I am not the author of Phar, but I am the current maintainer, so I'll do my
best to help. I am responding to your comments here so we can discuss, but
I encourage you to open a request at bugs.php.net so that we can track and
act on it.

I am trying to get bcgen to work with PHAR files. I have added the
> compiled PHP files to the PHAR file (using their PHP extension within
> the PHAR file)
>
> The stub of the PHP archive is:
>
> |#!/usr/bin/env php|
> |<?php|
> |Phar::mapPhar( 'app.phar' );|
> |set_include_path( 'phar://app.phar' . PATH_SEPARATOR.';.');|
> |require('phar://' . __FILE__ . '/app.php');|
> |__HALT_COMPILER(); |?>
>
> The file app.php is in the root of the PHAR archive and is compiled by
> bcgen.
>
> When I run the phar (on the commandline), all I get is some gibberish
> output (to STDOUT) and the process exits with exitcode 130 ?
>

In my experience, exit codes above 128 indicate the process received a
signal, whose number is the difference between the exit code and 128. So,
130 - 128 = 2, and signal 2 is "Interrupt", which I usually associate with
the shell receiving a keystroke of Control+C. Is that what happened?

If not, we'll need a similar app.php to explore this further.

My understanding is that bcgen extension will inspect the file which is
> included/required (ie. app.php) and then - if it is bytecode - then
> simply execute the bytecode - If it is not, then it will parse the
> included file normally ? (from the description found in the README of
> bcgen in github)
>

While I'm grossly simplifying for purposes of discussion here, phar is
fundamentally a file archive format: think Zip or Tar file. When you open a
file on the phar:// stream, you're asking the phar subsystem to expand the
given path out of the archive and make it available to the caller as if it
were locally available at that path.

There are some gymnastics here to make that possible, and those might be
what's causing the incompatibility you've seen, but it sounds like it might
be a problem not with bcgen, or with phar, but with how the two are trying
to work together.

However it seems that what actually happens, is that the header of the
> PHAR file itself is checked and since that is obviously not a BCGEN
> header or a normal PHP file, processing is aborted.
>

If bcgen is inspecting the header of the phar, that suggests to me bcgen
needs some logic to detect the phar and open it as a phar stream instead of
attempting to read it as either binary or text. Said another way, if bcgen
is doing a simple "if has certain magic number in first N bytes then is
byte code else is php text" that logic won't work, if you're passing a
whole phar to bcgen. On the other hand, if bcgen intercepts calls to
include (and friends), it should transparently see either bytecode or php
text, because the phar subsystem has already expanded the file in place.
Either way, this sounds like an incompatibility between the two that should
probably be explored on the bcgen side.

If we could skip this check when running from a PHAR archive (from the
> commandline or when the PHAR is included within some other PHP file) and
> in this scenario only "react" to include/require/autoloading statements
> (ie. check if a file that is about to be included is bytecode or not -
> if it is, then run it - If it is not then compile it first and then run
> the resulting bytecode), then - in my humble opinion - we would have a
> way of adding minimal protection to PHAR files - useful when
> redistributing PHARs (since such a PHAR archive would then simply
> contain a number of files that are bytecode - except for the stub of
> course...) and that would - I think - make PHAR files even cooler and
> provide a most sought-after feature.
>

What you describe sounds like my "bcgen hooks into include" scenario above,
which would be a change request for the bcgen authors. I don't know bcgen,
but if there's interest in getting the two to work together, I suggest
opening this request at bugs.php.net.

Could anyone help getting "PHAR support" to work with the bcgen
> extension ? I would be willing to help but my C skills are not that
> great and I know little about the ZendEngine.
>

Glad you're willing to help! You don't need to be a C expert, just have a
passion for PHP and a willingness to contribute where you can: like
providing great test cases, or writing clear docs.

Next step: open this issue at bugs.php.net with all the info necessary to
reproduce it. From there, I can run it in a debugger and step through the
code to spot the incompatibility.

--00000000000027f3250592fe4f7d--