http://svn.php.net/repository/php/php-src/branches/PHP_5_3 r318957
We also applied it to 5.3.8 release, although we had to fix up the patch for that. I can port it to 5.4. Edward Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
