Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.177 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <1390568541.2941.27.camel@guybrush>
References: <CBCB62C2-1E7E-4D92-B051-792D06970322@gmail.com> <1390568541.2941.27.camel@guybrush>
Date: Fri, 24 Jan 2014 15:01:31 +0100
Message-ID: <CAMUwpuTcxAW6y5ui=rVBNAHWsxn2zFFgCf_A1Q-uMS1byx_DZg@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: Sara Golemon <saramg@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Module API Introspection
From: jpauli@php.net (Julien Pauli)

On Fri, Jan 24, 2014 at 2:02 PM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> On Fri, 2014-01-24 at 11:31 +0100, Sara Golemon wrote:
>> http://wiki.php.net/rfc/moduleapi-inspection
>>
>
> the idea is neat, i however wonder how often this will not work due to
> missing symbols. At least on systems which support that we dlopen()
> using the DL_LOAD flag to lazy load which will often prevent that
> error.

Nice catch. However, sure, there will be failing cases like there are
when loading extensions.
We just can't get rid off them, and have to leave with them, like our
extension system works today.
Sara's patch anyway use the same macros used in the extension system
(DL_LOAD, particulary, which uses RTLD_LAZY).

>
> Cases where this can fail, form top of my head, are at least
>
>       * extensions trying to hack get_module() (if you are crazy you can
>         create your own get_module() which detects the PHP version and
>         does compatibility magic, one binary for all, yes that exists
>         and works)

Quiet uncommon isn't it ?
The same can be said with actual extension system, this can even lead
to security holes, but we just cant do anything about this.

>       * accessing PHP symbols from the init section (i.e. from default
>         constructors being called for global variables in C++
>         extensions)

Same : that is an edge case, pretty uncommon as well, 99.9% of
extension developpers dont do that.

>       * I think (didn't check) there will be issues due to tsrm symols
>         when an extension provides INI options and TSRM/non-TSRM doesn't
>         match

I don't get it. We access very few fields of zend_module_entry, and
they are all placed before the _zend_ini_entry one. So if there is a
problem of alignment mismatch, we won't be affected AFAIK.

>       * Afaik Windows' LoadLibrary doesn't do lazy loading but will
>         confront the user with a dialog box when symbols can't be found
>       * ... I'm sure there are more

Same : the same happens on WIndows when you try to load an extension.
So , we already manage this behavior and cant do anything about it.

Julien