Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:7430 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5824 invoked by uid 1010); 30 Jan 2004 18:17:42 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 5752 invoked from network); 30 Jan 2004 18:17:41 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 30 Jan 2004 18:17:41 -0000 Received: (qmail 1161 invoked from network); 30 Jan 2004 18:17:39 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 30 Jan 2004 18:17:39 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: Rasmus Lerdorf , internals@lists.php.net, "Andi Gutmans" , "Zeev Suraski" Date: Fri, 30 Jan 2004 13:17:43 -0500 User-Agent: KMail/1.5.94 References: <200401301235.01213.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_H/pGACjAEa7AWvB" Message-ID: <200401301317.43714.ilia@prohost.org> Subject: Re: [PHP-DEV] Warnings in include files suddenly treated as fatal From: ilia@prohost.org (Ilia Alshanetsky) --Boundary-00=_H/pGACjAEa7AWvB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is the final revision of the patch for the situation, if there are no last minute objections, it'll go in the CVS and we'll proceed with RC2. Ilia On January 30, 2004 12:37 pm, Rasmus Lerdorf wrote: > On Fri, 30 Jan 2004, Ilia Alshanetsky wrote: > > 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. > > Since this only happens on an error condition I guess it is ok. Just > seems like we should be able to set some kind of hint in Zend to pass > this information back up. > > -Rasmus --Boundary-00=_H/pGACjAEa7AWvB Content-Type: text/plain; charset="iso-8859-1"; name="zeinc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="zeinc.txt" Index: zend_execute.c =================================================================== RCS file: /repository/ZendEngine2/zend_execute.c,v retrieving revision 1.592 diff -u -3 -p -r1.592 zend_execute.c --- zend_execute.c 30 Jan 2004 02:22:17 -0000 1.592 +++ zend_execute.c 30 Jan 2004 18:16:32 -0000 @@ -3390,7 +3390,24 @@ int zend_include_or_eval_handler(ZEND_OP case ZEND_REQUIRE: new_op_array = compile_filename(EX(opline)->op2.u.constant.value.lval, inc_filename TSRMLS_CC); if (!new_op_array) { - zend_error(E_ERROR, "Parse error inside included file."); + /* small optimization for require() */ + if (EX(opline)->op2.u.constant.value.lval == ZEND_REQUIRE) { + goto fatal_error; + } else { + /* This check is needed to ensure that included file has a parse error + * and we are no dealing with a non-existant include, which is not considered + * to be a fatal error. + */ + zend_file_handle file_handle; + zend_bool can_open = zend_stream_open(inc_filename->value.str.val, &file_handle TSRMLS_CC); + zend_file_handle_dtor(&file_handle); + + /* file open succeeded but still no op-array, likely parse error */ + if (can_open == SUCCESS) { +fatal_error: + zend_error(E_ERROR, "Parse error inside included file."); + } + } } break; case ZEND_EVAL: { --Boundary-00=_H/pGACjAEa7AWvB--