Edit report at https://bugs.php.net/bug.php?id=45421&edit=1

 ID:                 45421
 Comment by:         ashley at netspot dot com dot au
 Reported by:        rpeters at icomproductions dot ca
 Summary:            Runtime equivilant of __FILE__
 Status:             Not a bug
 Type:               Feature/Change Request
 Package:            *General Issues
 Operating System:   CentOS 4.3
 PHP Version:        5.2.6
 Block user comment: N
 Private report:     N

 New Comment:

I have to agree with rpeters here - this is a bug because __FILE__ and __DIR__ 
break opcode caches and there isn't a workaround.  In order to work around the 
problem, there needs to be a run-time call available which will return the full 
path to the current file (the equivilent of __FILE__ but at run time).  Same 
with 
__DIR__.

The opcode caches work by hashing the source and assuming that if two source 
files are identical then their opcodes are identical, but unfortunately this is 
not the case because of the magic constants that get replaced during 
compilation.  
This means that we can't make efficient use of opcode caches if we have 
multiple 
copies and/or hardlinks of the same file.

>From my understanding, this bug is just a request to have a runtime call added 
>so 
we can get the equivilent of __FILE__ and __DIR__ at runtime.


Previous Comments:
------------------------------------------------------------------------
[2011-04-27 10:47:40] simpcl2008 at gmail dot com

BTW, 
use "executed_filename" to instead of "__FILE__".

------------------------------------------------------------------------
[2011-04-27 10:41:39] simpcl2008 at gmail dot com

The patch of apc_auto_hardlinks_for_php_5.3.5.diff is to add a new key word 
"executed_filename" for PHP 5.3.5 . 

When the following code is running:
<?php
echo executed_filename;
?>

In PHP Runtime, zend_get_executed_filename() is called to returned the current 
runtime filename and being displayed.

To fixed the apc hardlinks programs, the apc source code "apc_main.c" should 
also to be modified as follows:

--- APC-3.1.6/apc_main.c        2010-11-30 18:18:31.000000000 +0800
+++ APC-3.1.6-sae/apc_main.c    2011-04-27 15:56:34.000000000 +0800
@@ -559,6 +559,7 @@ static zend_op_array* my_compile_file(ze
             if (h->type != ZEND_HANDLE_FILENAME) {
                 zend_llist_add_element(&CG(open_files), h); 
             }
+            op_array->filename = estrdup(filename);
             return op_array;
         }
         if(APCG(report_autofilter)) {

------------------------------------------------------------------------
[2011-01-24 23:52:27] rpeters at icomproductions dot ca

I am once again asking the PHP devs to implement this feature, or at the very 
least reconsider flagging this as "Bogus". This is a legitimate feature request 
with a very significant upside, and marking it as "Bogus" and then telling me 
to code it myself seems inappropriate.

Either you are against the request, or it should remain as a request that a 
core developer can implement.

------------------------------------------------------------------------
[2009-08-19 21:51:20] rpeters at icomproductions dot ca

I don't have the expertise to develop a patch for PHP.

And the issue with PHP is that it's currently impossible for opcode caches to 
correctly deal with __FILE__ in a hardlinked file.

This is due to the fact that __FILE__ (and __DIR__) is inherently dynamic, but 
is compiled as a constant. _That's_ PHP's problem.

There are currently no workarounds or any other mechanisms for allowing proper 
opcode caching. There is no way for a third party to work around this PHP 
design flaw, only you have the power to change this.

Hence the _feature request_ (not bug report) that one be introduced.

I think it's in everyone's best interest if PHP opcaches are usable in more 
situations than are currently possible.

------------------------------------------------------------------------
[2009-08-19 18:05:16] scott...@php.net

There isn't anything to fix in PHP, if you think we should do something 
differently then please submit a patch and we'll review it.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=45421


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=45421&edit=1

Reply via email to