Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.44 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <1390572927.2941.37.camel@guybrush>
References: <CBCB62C2-1E7E-4D92-B051-792D06970322@gmail.com>
 <1390568541.2941.27.camel@guybrush> <CAMUwpuTcxAW6y5ui=rVBNAHWsxn2zFFgCf_A1Q-uMS1byx_DZg@mail.gmail.com>
 <1390572927.2941.37.camel@guybrush>
Date: Fri, 24 Jan 2014 15:29:53 +0100
Message-ID: <CAMUwpuTRSYw65M5++sc4qw5MDwBDsSaxCbHk7BmJUSyC=auekA@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 3:15 PM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> On Fri, 2014-01-24 at 15:01 +0100, Julien Pauli wrote:
>> >       * 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.
>>
> INI settings are in a global variable, referring to specific update
> handlers. I remember cases where the error while loading extensions was
> about missing OnUpdateBool. I can imagine other similar errors.
>
>> >       * 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.
>>
> The point is: What is the benefit of such a feature if it often can't be
> used? Maybe we can think more and find a better way to approach this?

I'm all open to new ideas :-)

> I don't have a better idea than something like a shell script doing
> `strings xdebug.so | grep API` -- which obviously is no good idea
> either, but maybe somebody is smarter than me.

That's what we ended telling to attendees : we have no way in PHP
actually to check the API of an extension, except by trying to load
it.
However, GNU tools playing with ELF format are a global Unix solution
working, but not coming from PHP obviously.

The only safe thing we could do, is wrapping libelf and play with it.
Somehow dirty and adds a new dependency :-p

Julien