If I'm not wrong, this only breaks APC when include_once_override is turned on.
My vote is to drop the apc.include_once_override and make APC a bit
simpler & neater.
I've found that it behaves rather inconsistently when people start
returning values from scripts.
<?php
function f($a = array(1)) { return $a; }
return f();
has been a suspect case for some segvs.
Cheers,
Gopal
On Sun, Oct 28, 2012 at 12:02 PM, Rasmus Lerdorf <[email protected]> wrote:
> On 10/27/2012 03:50 PM, Stas Malyshev wrote:
>> Hi!
>>
>>> An APC-level fix might be to fix the include_once/require_once override
>>> implementation to go to the cache first to see if the inode is there and
>>> pull out the cached realpath and use that to check against the
>>> included_files list. The downside is that we will likely end up with 2
>>> cache lookups on every include_once.
>>
>> Comparing inodes sounds like a good idea for APC. Or, rather, comparing
>> device,inode tuples. However, it should be able to fall back to
>> comparing paths for files that have no inode.
>>
>> However, this may lead to BC break in (admittedly very unlikely)
>> scenario of file hardlinked under two different names.
>>
>
> Ok, I have a working implementation which uses the normal APC cache
> lookup mechanism which by default will use an inode lookup, so through
> that we get the device+inode check, and it will then pull the realpath
> instead of going through VCWD_REALPATH() to get a possibly incorrect
> one. See the attached patch. This takes care of the hardlink scenario as
> well because it checks both the inode and the cached path. Anyone see
> any holes in this approach?
>
> -Rasmus
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
