Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 30 Jan 2004 09:03:41 -0800 (PST)
To: Ilia Alshanetsky <ilia@prohost.org>
cc: internals@lists.php.net
In-Reply-To: <200401300959.41785.ilia@prohost.org>
Message-ID: <Pine.LNX.4.58.0401300901200.1031@thinkpad.lerdorf.com>
References: <Pine.WNT.4.56.0401300224280.3568@DELL> <200401300959.41785.ilia@prohost.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Warnings in include files suddenly treated as fatal
From: rasmus@php.net (Rasmus Lerdorf)

On Fri, 30 Jan 2004, 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.

Granted, I haven't looked closely at the code, but PHP knows that failure 
to open an include file is an E_WARNING not an E_ERROR.  An E_WARNING 
should never cause script execution to terminate.  If we already know it 
is non-fatal, why is the extra check needed?

-Rasmus