Re: Warnings in include files suddenly treated as fatal

I think I missed out on the original problem. What does the fix, fix? Isn't a parse error automatically a fatal error? 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