Re: bug #48583 or display_errors saga

On Jun 18, 2009, at 1:09 PM, jvlad wrote:

If the bug #48583 can't be accepted through bugs.php.net, I think it makes sense to discuss it here.

It's not a bug but "chicken'n'egg'" issue. Errors are displayed by default (IIRC) so if the ini file does not get parsed an error is outputted which IS --Jani

I don't agree, absolutely. Settings are more important and should be parsed/loaded first. If any error happens before this phase is complete, they should be captured and buffered for later processing, unless the error is fatal. After the settings are loaded, all buffered errors should be processed and handled according to the settings. Nothing else. Do you see any problems with this approach? Where is the promissed chicken&egg issue? :)

really good thing. Just fix that damn ini file. :)

Sorry, but seems you do not understand the situation. How would an admin fix that damn ini file if the errors are not appearing in the log????? Say, I'm a hosting company admin. I install packages, php in particular, make changes to configs, etc. I do not know what web sites are running and do not want to see if anything related to my work appear in their pages. Never. What steps am I supposed to do to see that php.ini contains bogus #? Take in to account that some of the errors do not appear in the output at all. They are crashing php because passed to the handler too early.

I have to say I agree; exposing such errors can be a potential security risk. -- Gwynne