If you revert your patch what won't work?
Andi
At 09:59 AM 1/30/2004 -0500, Ilia Alshanetsky wrote:
It seems like the only way to distinguish between a parse error and a non-existant file for regular include() is by doing a zend_stream_open() upon failure to determine if the file is avaliable. If it is, then we return a parse error and if it does not we continue execution. This does add a small overhead for failed includes, but IMHO if a non-existant files are being included performance is not a big consideration.
That said, if there is much opposition to the approach I would be happy to revert the code to the previous state.
Ilia
P.S. Suggested 'fix' is attached.
On January 30, 2004 05:29 am, Rasmus Lerdorf wrote: > Ilia, I think there is a problem with your latest fixes on the 4_3 branch. > Stuff that used to work is now broken. Stuff like this: > > main.php: > > include 'inc1.inc'; > > inc1.inc: > > @include 'inc2.inc'; > > If inc2.inc does not exist we now get an error similar to: > > Warning: main(./lang/serendipity_lang_.inc.php): failed to open stream: No > such file or directory in /var/www/s9y/serendipity_lang.inc.php on line 5 > > Warning: main(): Failed opening './inc2.inc' for > inclusion (include_path='.:/usr/local/lib/php') on line {the include line > #} > > Fatal error: Parse error inside included file. in > /var/www/htdocs/inc1.inc on line {the include line #} > > Remember that it is ok for an include to not find the file. We issue a > warning and move on. It should in no way be treated as a fatal error. > > -Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
