Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6551 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96903 invoked by uid 1010); 18 Dec 2003 17:48:05 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 96879 invoked from network); 18 Dec 2003 17:48:05 -0000 Received: from unknown (HELO sys30.mail.msu.edu) (35.9.75.130) by pb1.pair.com with SMTP; 18 Dec 2003 17:48:05 -0000 Received: from 66-65-38-11.nyc.rr.com ([66.65.38.11] helo=chiaraquartet.net) by sys30.mail.msu.edu with asmtp (Exim 4.24 #13) (TLSv1:AES256-SHA:256) id 1AX2Fe-0001UW-3A; Thu, 18 Dec 2003 12:47:54 -0500 Message-ID: <3FE1E851.6090803@chiaraquartet.net> Date: Thu, 18 Dec 2003 12:48:01 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schneider CC: Daniel Convissor , PHP Internals List References: <20031218124303.18e22274.paj@pearfr.org> <20031218140527.GA26390@panix.com> <3FE1D96B.3090308@chiaraquartet.net> <20031218170305.GA16670@panix.com> <3FE1DEF9.4060705@chiaraquartet.net> <20031218171530.GA17635@panix.com> <3FE1E318.3060004@cschneid.com> In-Reply-To: <3FE1E318.3060004@cschneid.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus: None found by Clam AV Subject: Re: [PHP-DEV] B3, pear segfault, and msgs about deprecated From: greg@chiaraquartet.net (Greg Beaver) At the least, this needs to be added to the thin-changes file, as it will bork any script that uses a custom error handler and has PHP 4 objects. Thanks for the catch Dan, that fixes it. Greg Christian Schneider wrote: > Daniel Convissor wrote: > >> It's the custom error handler in pearcmd.php. PHP doesn't pay attention >> to any error_reporting() settings when a custom error handler is >> established. Then, error_handler() doesn't account for the new warning >> level. > > > Is it just me or is this undesired behaviour? I noticed this back when I > was playing around with error_handlers. > > I think this should be treated as a bug and be changed for two reasons: > 1) It seems illogical that an error_handler is called for an error level > which is disabled in php.ini > 2) It's a performance issue since the custom error handler is called for > e.g. every access to an undefined array index even though I disabled > that warning. > > Opinions? > - Chris