Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Sara Golemon <saramg@gmail.com>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CBCB62C2-1E7E-4D92-B051-792D06970322@gmail.com>
References: <CBCB62C2-1E7E-4D92-B051-792D06970322@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 24 Jan 2014 14:02:21 +0100
Message-ID: <1390568541.2941.27.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Module API Introspection
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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. 

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)
      * accessing PHP symbols from the init section (i.e. from default
        constructors being called for global variables in C++
        extensions)
      * 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
      * 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

johannes