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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
