Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56286
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.44 cause and error)
Message-ID: <4EBD79A5.2020604@lerdorf.com>
Date: Fri, 11 Nov 2011 11:38:13 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: "Edward Z. Yang" <ezyang@MIT.EDU>
CC: internals <internals@lists.php.net>
References: <1320740449-sup-5688@ezyang> <4EB8EAF1.3040104@lerdorf.com> <1320981061-sup-2803@ezyang>
In-Reply-To: <1320981061-sup-2803@ezyang>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Load extensions for .user.ini files
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk

It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.

On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
> Here is the proposed patch (sans tests; we did our own manual testing
> on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
> tests when you say so):
> 
>     http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch
> 
> The change to zlist_clean is necessary because otherwise extension_lists can't
> be reused for the second round of extension appliations (since the head and
> tail pointers have garbage in them).  You should probably take that fix regardless
> of what you think of the feature change.
> 
> Edward
> 
> Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011:
>> On 11/08/2011 12:23 AM, Edward Z. Yang wrote:
>>> Hello all,
>>>
>>> My team is interested in permitting .user.ini files to load
>>> extensions.  We believe this to be a simple fix: add
>>> an invocation of php_ini_register_extensions to the end
>>> of sapi/cgi/cgi-main.c.
>>>
>>> I don't believe this steps on any invariants, since extensions
>>> can usually be loaded arbitrarily late.
>>>
>>> Let me know what the list thinks.  I can submit a patch and tests
>>> if y'all decide it's a good idea.
>>
>> You are aware that these extensions can't be unloaded, right? So one
>> user loading an extension will potentially be stepping on another user
>> and breaking their code.
>>
>> -Rasmus