Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:7428 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60545 invoked by uid 1010); 30 Jan 2004 17:34:58 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 60521 invoked from network); 30 Jan 2004 17:34:57 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 30 Jan 2004 17:34:57 -0000 Received: (qmail 756 invoked from network); 30 Jan 2004 17:34:57 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 30 Jan 2004 17:34:57 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: Rasmus Lerdorf , internals@lists.php.net Date: Fri, 30 Jan 2004 12:35:01 -0500 User-Agent: KMail/1.5.94 References: <200401300959.41785.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200401301235.01213.ilia@prohost.org> Subject: Re: [PHP-DEV] Warnings in include files suddenly treated as fatal From: ilia@prohost.org (Ilia Alshanetsky) On January 30, 2004 12:03 pm, Rasmus Lerdorf wrote: > 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? A parse error is an interesting beast because unlike other fatal errors it is not handled by PHP's error handler inside main.c. It is not done there since that would leak the stdio stream opened in ZE. Inside the regular require/include we have very little data to see what happened, we only know what op_array is NULL. Whether this happend due to a parse error or a not found file is unknown. So there are 3 possibilities @ this point: -> included file was not found -> included file was found, but has a parse error -> required file was found, but has a parse error (if requires was was not found, ZE would've already bailed out). Since we do not know which of the 3 occured, although I suppose the require situation can be optimized to: if (!new_op_array && ... == ZEND_REQUIRE) For include situation we need to see if the error is due to the file not being there, in which case we can go forward with execution, or if the problem was due to a parse error, in which case we need to stop. The easiest way I saw of doing it (without modifying too much existing code) was to perform a zend_stream_open(), which would check if the file is avaliable. Ilia