Req #60024 [Dup]: Do not keep last element treated by foreach referenced
Edit report at https://bugs.php.net/bug.php?id=60024&edit=1 ID: 60024 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:Do not keep last element treated by foreach referenced Status: Duplicate Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Could the discussion be linked to? This is not a duplicate of any of the reports indicated. The reports indicated are reports of application bugs as PHP bugs, which are therefore invalid. This report is asking to change PHP, in order to avoid such application bugs. Previous Comments: [2012-02-06 00:53:13] ahar...@php.net This has previously been discussed and rejected, due to users relying both on PHP's lack of block scope and foreach's by-reference syntax. (Sometimes both at once, unfortunately.) Duplicate of bug #29992, bug #47388, bug #54189, bug #50485, and probably a bunch of others. [2012-02-06 00:47:50] DeveloperGuy2008 at yahoo dot com Please fix this. It creates a lot of hard to debug bugs. [2011-10-09 21:09:19] chealer at gmail dot com Description: As explained on http://ca.php.net/manual/en/control-structures.foreach.php : Warning Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset(). In my opinion, PHP shouldn't keep the last element referenced by default, but at least, please provide a syntax which will not keep it. The current situations causes bugs like https://bugs.php.net/bug.php?id=49386 -- Edit this bug report at https://bugs.php.net/bug.php?id=60024&edit=1
Req #60024 [Dup]: Do not keep last element treated by foreach referenced
Edit report at https://bugs.php.net/bug.php?id=60024&edit=1 ID: 60024 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:Do not keep last element treated by foreach referenced Status: Duplicate Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Thank you. I read the discussion once, but I didn't see where it rejects this. Could the rejections be quoted or pointed more specifically? Previous Comments: [2012-02-07 00:10:38] ahar...@php.net Sure, it's come up on the mailing list a few times, but the one I was thinking of specifically is: http://comments.gmane.org/gmane.comp.php.devel/59471 [2012-02-06 22:24:17] chealer at gmail dot com Could the discussion be linked to? This is not a duplicate of any of the reports indicated. The reports indicated are reports of application bugs as PHP bugs, which are therefore invalid. This report is asking to change PHP, in order to avoid such application bugs. [2012-02-06 00:53:13] ahar...@php.net This has previously been discussed and rejected, due to users relying both on PHP's lack of block scope and foreach's by-reference syntax. (Sometimes both at once, unfortunately.) Duplicate of bug #29992, bug #47388, bug #54189, bug #50485, and probably a bunch of others. [2012-02-06 00:47:50] DeveloperGuy2008 at yahoo dot com Please fix this. It creates a lot of hard to debug bugs. ---- [2011-10-09 21:09:19] chealer at gmail dot com Description: As explained on http://ca.php.net/manual/en/control-structures.foreach.php : Warning Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset(). In my opinion, PHP shouldn't keep the last element referenced by default, but at least, please provide a syntax which will not keep it. The current situations causes bugs like https://bugs.php.net/bug.php?id=49386 -- Edit this bug report at https://bugs.php.net/bug.php?id=60024&edit=1
[PHP-BUG] Bug #61091 [NEW]: User-defined error handler run despite at sign (@) error control operator
From:
Operating system:
PHP version: 5.3.10
Package: *General Issues
Bug Type: Bug
Bug description:User-defined error handler run despite at sign (@) error
control operator
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, user-defined error handlers registered with set_error_handler()
are nevertheless run when @ is used, which often causes such messages to
show, as in the below example, where a custom error handler is used to
customize the display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895
and http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042
show, this problem is not new. This behavior appears to be by design, and
might be wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This
needs serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;
default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}
return $temp;
}
$a = array(2, 3, "foo", 5.5, 43.3, 21.11);
/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);
set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);
?>
Expected result:
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42
Actual result:
--
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42
My NOTICE [1024] Value at position 2 is not a number, using 0
(zero)
--
Edit bug report at https://bugs.php.net/bug.php?id=61091&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61091&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61091&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61091&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61091&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61091&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61091&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61091&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61091&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61091&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61091&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61091&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61091&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61091
Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61091&edit=1
ID: 61091
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thanks rasmus, but I do not see this explanation. Could you quote it?
Previous Comments:
[2012-02-15 03:45:12] ras...@php.net
This is very much by design and definitely won't be changed since that would
break all sorts of code. It is also explicitly documented at
http://www.php.net/set_error_handler which explains that the user-defined error
handler should check the error_reporting level in order to comply with the '@'
if
so desired.
[2012-02-15 03:06:15] chealer at gmail dot com
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, user-defined error handlers registered with set_error_handler() are
nevertheless run when @ is used, which often causes such messages to show, as
in the below example, where a custom error handler is used to customize the
display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show,
this problem is not new. This behavior appears to be by design, and might be
wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;
default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}
return $temp;
}
$a = array(2, 3, "foo", 5.5, 43.3, 21.11);
/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);
set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);
?>
Expected result:
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo', 3 =>
5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898) /var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a number,
using 0 (zero)', 1024) /var/www/atoperator.php:42
Actual result:
--
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo', 3 =>
5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898) /var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a number,
using 0 (zero)', 1024) /var/www/atoperator.php:42
My NOTICE [1024] Value at position 2 is not a number, using 0 (zero)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61091&edit=1
Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61091&edit=1
ID: 61091
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Rasmus, the part you quoted is about error_reporting() settings, it merely
mentions the error control operator.
My question was, could you quote where "http://www.php.net/set_error_handler
[...] explains that the user-defined error
handler should check the error_reporting level in order to comply with the '@'
if so desired"?
Previous Comments:
[2012-02-15 16:53:06] ras...@php.net
"error_reporting() settings will have no effect and your error handler will be
called regardless - however you are still able to read the current value of
error_reporting and act appropriately. Of particular note is that this value
will
be 0 if the statement that caused the error was prepended by the @
error-control
operator."
--------
[2012-02-15 16:25:42] chealer at gmail dot com
Thanks rasmus, but I do not see this explanation. Could you quote it?
[2012-02-15 03:45:12] ras...@php.net
This is very much by design and definitely won't be changed since that would
break all sorts of code. It is also explicitly documented at
http://www.php.net/set_error_handler which explains that the user-defined error
handler should check the error_reporting level in order to comply with the '@'
if
so desired.
--------------------
[2012-02-15 03:06:15] chealer at gmail dot com
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, user-defined error handlers registered with set_error_handler() are
nevertheless run when @ is used, which often causes such messages to show, as
in the below example, where a custom error handler is used to customize the
display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show,
this problem is not new. This behavior appears to be by design, and might be
wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;
default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}
return $temp;
}
$a = array(2, 3, "foo", 5.5, 43.3, 21.11);
/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);
set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);
?>
Expected result:
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2
Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61091&edit=1 ID: 61091 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:User-defined error handler run despite at sign (@) error control operator Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I guess it does, but this report is not about error_reporting, it is about the @ error control operator. According to the documentation of @, any error message that might be generated by the expression will be "ignored". Either the PHP interpreter is changed so that this becomes the case, or, if the current behavior is desired, the documentation is adapted to reflect the actual semantics. To be perfectly clear, I am not asking to change the de facto semantics. I am only asking that whatever semantics is used by the implementation matches the documented semantics. Previous Comments: [2012-02-19 20:24:52] ras...@php.net It says, "however you are still able to read the current value of error_reporting and act appropriately" followed by "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator." To me this says quite clearly that error_reporting will be 0 if the @ was used and that your custom error handler can read this value and "act appropriately." ---------------- [2012-02-19 19:49:22] chealer at gmail dot com Rasmus, the part you quoted is about error_reporting() settings, it merely mentions the error control operator. My question was, could you quote where "http://www.php.net/set_error_handler [...] explains that the user-defined error handler should check the error_reporting level in order to comply with the '@' if so desired"? [2012-02-15 16:53:06] ras...@php.net "error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator." -------------------- [2012-02-15 16:25:42] chealer at gmail dot com Thanks rasmus, but I do not see this explanation. Could you quote it? [2012-02-15 03:45:12] ras...@php.net This is very much by design and definitely won't be changed since that would break all sorts of code. It is also explicitly documented at http://www.php.net/set_error_handler which explains that the user-defined error handler should check the error_reporting level in order to comply with the '@' if so desired. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61091 -- Edit this bug report at https://bugs.php.net/bug.php?id=61091&edit=1
Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61091&edit=1 ID: 61091 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:User-defined error handler run despite at sign (@) error control operator Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I understand that this problem only happens when using a custom error handler. But, if we assume the bug is in the documentation, the documentation should not assume the error handler used is the standard one. The problem I'm reporting here is not that the documentation doesn't explain how custom error handlers should be written, it's just the quoted statement, which is wrong in certain cases. Alternatively, if the documentation of the @ operator isn't amended because custom error handlers are considered a corner case, then the set_error_handler() documentation should warn developers tempted to use custom error handlers that they are non-standard, not recommended/supported, and try to explain the pitfalls. In short, tell developers they should only use a custom error handler if they know what they're doing. However, this alternative should be avoided since set_error_handler() is already used in several applications whose developers didn't receive the warning. Previous Comments: [2012-02-19 22:38:57] ras...@php.net But it is unless you choose to override the default behaviour. And the documentation you hit when you do this override tells you how to check for @. -------- [2012-02-19 21:59:53] chealer at gmail dot com I guess it does, but this report is not about error_reporting, it is about the @ error control operator. According to the documentation of @, any error message that might be generated by the expression will be "ignored". Either the PHP interpreter is changed so that this becomes the case, or, if the current behavior is desired, the documentation is adapted to reflect the actual semantics. To be perfectly clear, I am not asking to change the de facto semantics. I am only asking that whatever semantics is used by the implementation matches the documented semantics. [2012-02-19 20:24:52] ras...@php.net It says, "however you are still able to read the current value of error_reporting and act appropriately" followed by "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator." To me this says quite clearly that error_reporting will be 0 if the @ was used and that your custom error handler can read this value and "act appropriately." -------------------- [2012-02-19 19:49:22] chealer at gmail dot com Rasmus, the part you quoted is about error_reporting() settings, it merely mentions the error control operator. My question was, could you quote where "http://www.php.net/set_error_handler [...] explains that the user-defined error handler should check the error_reporting level in order to comply with the '@' if so desired"? [2012-02-15 16:53:06] ras...@php.net "error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator." The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61091 -- Edit this bug report at https://bugs.php.net/bug.php?id=61091&edit=1
[PHP-BUG] Bug #61747 [NEW]: User-defined error handler run despite at sign (@) error control operator
From:
Operating system:
PHP version: 5.4.0
Package: *General Issues
Bug Type: Bug
Bug description:User-defined error handler run despite at sign (@) error
control operator
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, as reported in #61091, user-defined error handlers registered with
set_error_handler() are nevertheless run when @ is used, which often causes
such messages to show, as in the below example, where a custom error
handler is used to customize the display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895
and http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042
show, this problem is not new. This behavior appears to be by design, and
might be wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This
needs serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Alternatively, if the documentation of the @ operator isn't amended because
custom error handlers are considered a corner case, then the
set_error_handler() documentation should warn developers tempted to use
custom error handlers that they are non-standard, not
recommended/supported, and try to explain the pitfalls. In short, tell
developers they should only use a custom error handler if they know what
they're doing.
However, this alternative should be avoided since set_error_handler() is
already used in several applications whose developers didn't receive the
warning.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;
default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}
return $temp;
}
$a = array(2, 3, "foo", 5.5, 43.3, 21.11);
/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);
set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);
?>
Expected result:
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42
Actual result:
--
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42
Call Stack:
0.0005 339192 1. {main}() /var/www/atoperator.php:0
0.0005 339836 2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648 3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42
My NOTICE [1024] Value at position 2 is not a number, using 0
(zero)
--
Edit bug report at https://bugs.php.net/bug.php?id=61747&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61747&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61747&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61747&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61747&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61747&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61747&r=alreadyfixed
Need bac
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I'm sorry. This was fixed in
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
If you have set a custom error handler function with set_error_handler() then
it will still get called, but this custom error handler can (and should) call
error_reporting() which will return 0 when the call that triggered the error
was preceded by an @.
Note that this second sentence contradicts the first in some [edge] cases. At
least, the second sentence should immediately follow the first, rather than
having its own paragraph.
Previous Comments:
[2012-04-16 20:39:54] ras...@php.net
The documentation is quite clear I think. In the first link you provided it
says:
If you have set a custom error handler function with set_error_handler()
then it will still get called, but this custom error handler can
(and should) call error_reporting() which will return 0 when the call
that triggered the error was preceded by an @.
I see no reason to change anything here. The current approach gives you all the
control you need. If you have a custom error handler you can decide whether you
want to ignore silenced calls or not. Any change to this would also be a major
BC break.
[2012-04-16 17:57:52] chealer at gmail dot com
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, as reported in #61091, user-defined error handlers registered with
set_error_handler() are nevertheless run when @ is used, which often causes
such messages to show, as in the below example, where a custom error handler is
used to customize the display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show,
this problem is not new. This behavior appears to be by design, and might be
wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Alternatively, if the documentation of the @ operator isn't amended because
custom error handlers are considered a corner case, then the
set_error_handler() documentation should warn developers tempted to use custom
error handlers that they are non-standard, not recommended/supported, and try
to explain the pitfalls. In short, tell developers they should only use a
custom error handler if they know what they're doing.
However, this alternative should be avoided since set_error_handler() is
already used in several applications whose developers didn't receive the
warning.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;
case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;
default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}
// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}
if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}
$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE
Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61091&edit=1 ID: 61091 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:User-defined error handler run despite at sign (@) error control operator Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.3.10 Block user comment: N Private report: N New Comment: This was fixed by rasmus in http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370 See also #61747. Previous Comments: [2012-02-19 23:05:25] chealer at gmail dot com I understand that this problem only happens when using a custom error handler. But, if we assume the bug is in the documentation, the documentation should not assume the error handler used is the standard one. The problem I'm reporting here is not that the documentation doesn't explain how custom error handlers should be written, it's just the quoted statement, which is wrong in certain cases. Alternatively, if the documentation of the @ operator isn't amended because custom error handlers are considered a corner case, then the set_error_handler() documentation should warn developers tempted to use custom error handlers that they are non-standard, not recommended/supported, and try to explain the pitfalls. In short, tell developers they should only use a custom error handler if they know what they're doing. However, this alternative should be avoided since set_error_handler() is already used in several applications whose developers didn't receive the warning. [2012-02-19 22:38:57] ras...@php.net But it is unless you choose to override the default behaviour. And the documentation you hit when you do this override tells you how to check for @. -------- [2012-02-19 21:59:53] chealer at gmail dot com I guess it does, but this report is not about error_reporting, it is about the @ error control operator. According to the documentation of @, any error message that might be generated by the expression will be "ignored". Either the PHP interpreter is changed so that this becomes the case, or, if the current behavior is desired, the documentation is adapted to reflect the actual semantics. To be perfectly clear, I am not asking to change the de facto semantics. I am only asking that whatever semantics is used by the implementation matches the documented semantics. [2012-02-19 20:24:52] ras...@php.net It says, "however you are still able to read the current value of error_reporting and act appropriately" followed by "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator." To me this says quite clearly that error_reporting will be 0 if the @ was used and that your custom error handler can read this value and "act appropriately." -------------------- [2012-02-19 19:49:22] chealer at gmail dot com Rasmus, the part you quoted is about error_reporting() settings, it merely mentions the error control operator. My question was, could you quote where "http://www.php.net/set_error_handler [...] explains that the user-defined error handler should check the error_reporting level in order to comply with the '@' if so desired"? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61091 -- Edit this bug report at https://bugs.php.net/bug.php?id=61091&edit=1
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
This is a duplicate of #52338.
Note that I partly disagree with the fix. Custom error handlers *can* check
error_reporting(), as illustrated in the example from
http://ca3.php.net/manual/en/function.set-error-handler.php
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}
However, it would be rather inefficient if custom error handlers *should* (had
to) do that, in general. If that was the case, PHP should simply not call
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only
in some cases.
Previous Comments:
[2012-04-16 20:59:18] chealer at gmail dot com
I'm sorry. This was fixed in
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
If you have set a custom error handler function with set_error_handler() then
it will still get called, but this custom error handler can (and should) call
error_reporting() which will return 0 when the call that triggered the error
was preceded by an @.
Note that this second sentence contradicts the first in some [edge] cases. At
least, the second sentence should immediately follow the first, rather than
having its own paragraph.
[2012-04-16 20:39:54] ras...@php.net
The documentation is quite clear I think. In the first link you provided it
says:
If you have set a custom error handler function with set_error_handler()
then it will still get called, but this custom error handler can
(and should) call error_reporting() which will return 0 when the call
that triggered the error was preceded by an @.
I see no reason to change anything here. The current approach gives you all the
control you need. If you have a custom error handler you can decide whether you
want to ignore silenced calls or not. Any change to this would also be a major
BC break.
[2012-04-16 17:57:52] chealer at gmail dot com
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, as reported in #61091, user-defined error handlers registered with
set_error_handler() are nevertheless run when @ is used, which often causes
such messages to show, as in the below example, where a custom error handler is
used to customize the display of error messages.
As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show,
this problem is not new. This behavior appears to be by design, and might be
wanted in some cases.
Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.
Alternatively, if the documentation of the @ operator isn't amended because
custom error handlers are considered a corner case, then the
set_error_handler() documentation should warn developers tempted to use custom
error handlers that they are non-standard, not recommended/supported, and try
to explain the pitfalls. In short, tell developers they should only use a
custom error handler if they know what they're doing.
However, this alternative should be avoided since set_error_handler() is
already used in several applications whose developers didn't receive the
warning.
Test script:
---
My ERROR [$errno] $errstr\n";
echo " Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;
case E_USER_WARNING:
echo "My WARNING [
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I meant it would be inefficient to ask PHP programmers to include
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
in all custom error handlers they write, if the problem could be addressed once
and for all by the PHP interpreter.
If that is your stance though, this requirement should be documented in
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed
errors, then not calling custom error handlers would be more of a bugfix (for
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be
a "major BC break", although it may be disruptive enough to warrant waiting for
a major release to do such a behavior change.
I'm not saying there's something *wrong* (in the sense of buggy) with the
current implementation, as long as how it works is documented (which wasn't the
case until recently), and the requirement to check for suppressed errors is
documented in set_error_handler()'s documentation (which is still not the case).
Previous Comments:
[2012-04-16 21:31:03] ras...@php.net
There is nothing inefficient about calling error_reporting(). It is a trivially
small and fast internal function. And like I said, changing anything here would
be a major BC break. There is nothing wrong with the current implementation.
------------
[2012-04-16 21:23:27] chealer at gmail dot com
This is a duplicate of #52338.
Note that I partly disagree with the fix. Custom error handlers *can* check
error_reporting(), as illustrated in the example from
http://ca3.php.net/manual/en/function.set-error-handler.php
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}
However, it would be rather inefficient if custom error handlers *should* (had
to) do that, in general. If that was the case, PHP should simply not call
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only
in some cases.
----------------
[2012-04-16 20:59:18] chealer at gmail dot com
I'm sorry. This was fixed in
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
If you have set a custom error handler function with set_error_handler() then
it will still get called, but this custom error handler can (and should) call
error_reporting() which will return 0 when the call that triggered the error
was preceded by an @.
Note that this second sentence contradicts the first in some [edge] cases. At
least, the second sentence should immediately follow the first, rather than
having its own paragraph.
[2012-04-16 20:39:54] ras...@php.net
The documentation is quite clear I think. In the first link you provided it
says:
If you have set a custom error handler function with set_error_handler()
then it will still get called, but this custom error handler can
(and should) call error_reporting() which will return 0 when the call
that triggered the error was preceded by an @.
I see no reason to change anything here. The current approach gives you all the
control you need. If you have a custom error handler you can decide whether you
want to ignore silenced calls or not. Any change to this would also be a major
BC break.
--------------------
[2012-04-16 17:57:52] chealer at gmail dot com
Description:
The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php
When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored.
However, as reported in #61091, user-defined error handlers registered with
set_error_handler() are nevertheless run when @ is used, which often causes
such messages to show, as in the below examp
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
You write:
If you choose to treat @-preceded errors like any other error, that's fine.
Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors
like any other error call error_reporting()?
You write:
By default PHP ignores errors from calls preceded by @, but since you are
writing your own you should have the power to override any and all such
defaults.
I'm not sure I would say that custom error handlers *should* have the power to
override error suppression, but I certainly understand that it can be useful.
In any case, offering that flexibility doesn't have to make it more complicated
to write a simple custom handler. set_error_handler() could simply have an
argument to control whether the callback is called even on normally suppressed
errors.
Previous Comments:
[2012-04-16 22:34:14] ras...@php.net
I didn't say that I think custom error handlers should ignore suppressed
errors.
I said that the authors of the custom error handlers should decide what to do
with them so they should called error_reporting() and take an appropriate
action. I have seen systems that use the @ to classify something that generates
an E_WARNING as non-critical for example, where an E_WARNING without the @
causes someone to get paged.
And it is documented on the set_error_handler() page. It says:
error_reporting() settings will have no effect and your error handler
will be called regardless - however you are still able to read the
current value of error_reporting and act appropriately. Of particular
note is that this value will be 0 if the statement that caused the
error was prepended by the @ error-control operator.
The point of a custom error handler is to override the default PHP error
handling behaviour. By default PHP ignores errors from calls preceded by @, but
since you are writing your own you should have the power to override any and
all
such defaults. If you choose to treat @-preceded errors like any other error,
that's fine.
This really isn't going to change.
--------
[2012-04-16 21:50:00] chealer at gmail dot com
I meant it would be inefficient to ask PHP programmers to include
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
in all custom error handlers they write, if the problem could be addressed once
and for all by the PHP interpreter.
If that is your stance though, this requirement should be documented in
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed
errors, then not calling custom error handlers would be more of a bugfix (for
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be
a "major BC break", although it may be disruptive enough to warrant waiting for
a major release to do such a behavior change.
I'm not saying there's something *wrong* (in the sense of buggy) with the
current implementation, as long as how it works is documented (which wasn't the
case until recently), and the requirement to check for suppressed errors is
documented in set_error_handler()'s documentation (which is still not the case).
[2012-04-16 21:31:03] ras...@php.net
There is nothing inefficient about calling error_reporting(). It is a trivially
small and fast internal function. And like I said, changing anything here would
be a major BC break. There is nothing wrong with the current implementation.
--------------------
[2012-04-16 21:23:27] chealer at gmail dot com
This is a duplicate of #52338.
Note that I partly disagree with the fix. Custom error handlers *can* check
error_reporting(), as illustrated in the example from
http://ca3.php.net/manual/en/function.set-error-handler.php
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}
However, it would be rather inefficient if custom error handlers *shoul
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1
ID: 61747
User updated by:chealer at gmail dot com
Reported by:chealer at gmail dot com
Summary:User-defined error handler run despite at sign (@)
error control operator
Status: Not a bug
Type: Bug
Package:*General Issues
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Right. So, the documentation is saying custom error handlers should treat
suppressed errors differently. You are saying it is fine not to do that.
I think your version is right.
Previous Comments:
[2012-04-17 00:59:34] ras...@php.net
Right, it says "should" not "must". If you choose to not treat @ differently,
then you obviously don't need to call error_reporting() from your handler.
----
[2012-04-17 00:36:29] chealer at gmail dot com
You write:
If you choose to treat @-preceded errors like any other error, that's fine.
Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors
like any other error call error_reporting()?
You write:
By default PHP ignores errors from calls preceded by @, but since you are
writing your own you should have the power to override any and all such
defaults.
I'm not sure I would say that custom error handlers *should* have the power to
override error suppression, but I certainly understand that it can be useful.
In any case, offering that flexibility doesn't have to make it more complicated
to write a simple custom handler. set_error_handler() could simply have an
argument to control whether the callback is called even on normally suppressed
errors.
[2012-04-16 22:34:14] ras...@php.net
I didn't say that I think custom error handlers should ignore suppressed
errors.
I said that the authors of the custom error handlers should decide what to do
with them so they should called error_reporting() and take an appropriate
action. I have seen systems that use the @ to classify something that generates
an E_WARNING as non-critical for example, where an E_WARNING without the @
causes someone to get paged.
And it is documented on the set_error_handler() page. It says:
error_reporting() settings will have no effect and your error handler
will be called regardless - however you are still able to read the
current value of error_reporting and act appropriately. Of particular
note is that this value will be 0 if the statement that caused the
error was prepended by the @ error-control operator.
The point of a custom error handler is to override the default PHP error
handling behaviour. By default PHP ignores errors from calls preceded by @, but
since you are writing your own you should have the power to override any and
all
such defaults. If you choose to treat @-preceded errors like any other error,
that's fine.
This really isn't going to change.
----------------
[2012-04-16 21:50:00] chealer at gmail dot com
I meant it would be inefficient to ask PHP programmers to include
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
in all custom error handlers they write, if the problem could be addressed once
and for all by the PHP interpreter.
If that is your stance though, this requirement should be documented in
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed
errors, then not calling custom error handlers would be more of a bugfix (for
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be
a "major BC break", although it may be disruptive enough to warrant waiting for
a major release to do such a behavior change.
I'm not saying there's something *wrong* (in the sense of buggy) with the
current implementation, as long as how it works is documented (which wasn't the
case until recently), and the requirement to check for suppressed errors is
documented in set_error_handler()'s documentation (which is still not the case).
[2012-04-16 21:31:03] ras...@php.net
There is nothing inefficient about calling error_reporting(). It is a trivially
small and fast internal function. And like I said, changing anything here would
be a major BC break. There is nothing wrong with the current implementation.
--
Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator
Edit report at https://bugs.php.net/bug.php?id=61747&edit=1 ID: 61747 User updated by:chealer at gmail dot com Reported by:chealer at gmail dot com Summary:User-defined error handler run despite at sign (@) error control operator Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.4.0 Block user comment: N Private report: N New Comment: No what? It's not fine not to treat suppressed errors differently? Previous Comments: [2012-04-17 02:00:40] ras...@php.net No, I think a custom error handler should make good use of the silence operator. There are all kinds of interesting things you can do with it. But yes, if you want to ignore it entirely, that is fine too. [2012-04-17 01:40:34] chealer at gmail dot com Right. So, the documentation is saying custom error handlers should treat suppressed errors differently. You are saying it is fine not to do that. I think your version is right. [2012-04-17 00:59:34] ras...@php.net Right, it says "should" not "must". If you choose to not treat @ differently, then you obviously don't need to call error_reporting() from your handler. -------- [2012-04-17 00:36:29] chealer at gmail dot com You write: If you choose to treat @-preceded errors like any other error, that's fine. Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a custom error handler should call error_reporting(). So why should a custom error handler which chooses to treat @-preceded errors like any other error call error_reporting()? You write: By default PHP ignores errors from calls preceded by @, but since you are writing your own you should have the power to override any and all such defaults. I'm not sure I would say that custom error handlers *should* have the power to override error suppression, but I certainly understand that it can be useful. In any case, offering that flexibility doesn't have to make it more complicated to write a simple custom handler. set_error_handler() could simply have an argument to control whether the callback is called even on normally suppressed errors. [2012-04-16 22:34:14] ras...@php.net I didn't say that I think custom error handlers should ignore suppressed errors. I said that the authors of the custom error handlers should decide what to do with them so they should called error_reporting() and take an appropriate action. I have seen systems that use the @ to classify something that generates an E_WARNING as non-critical for example, where an E_WARNING without the @ causes someone to get paged. And it is documented on the set_error_handler() page. It says: error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator. The point of a custom error handler is to override the default PHP error handling behaviour. By default PHP ignores errors from calls preceded by @, but since you are writing your own you should have the power to override any and all such defaults. If you choose to treat @-preceded errors like any other error, that's fine. This really isn't going to change. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61747 -- Edit this bug report at https://bugs.php.net/bug.php?id=61747&edit=1
[PHP-BUG] Req #62132 [NEW]: Do not keep last element treated by foreach referenced
From: chealer at gmail dot com Operating system: PHP version: 5.4.3 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Do not keep last element treated by foreach referenced Description: As explained on http://ca.php.net/manual/en/control-structures.foreach.php : Warning Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset(). In my opinion, PHP shouldn't keep the last element referenced by default, but at least, please provide a syntax which will not keep it. The current situation causes bugs like: https://bugs.php.net/bug.php?id=29992 https://bugs.php.net/bug.php?id=40654 https://bugs.php.net/bug.php?id=47388 https://bugs.php.net/bug.php?id=49386 https://bugs.php.net/bug.php?id=50485 https://bugs.php.net/bug.php?id=54189 ahar...@php.net pointed out that this problem was already discussed (see https://bugs.php.net/bug.php?id=60024 ). -- Edit bug report at https://bugs.php.net/bug.php?id=62132&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62132&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62132&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62132&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62132&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62132&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62132&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62132&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62132&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62132&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62132&r=support Expected behavior: https://bugs.php.net/fix.php?id=62132&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62132&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62132&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62132&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62132&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62132&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62132&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62132&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62132&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62132&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62132&r=mysqlcfg
[PHP-BUG] Bug #52897 [NEW]: Strings variable parsing - complex syntax
From:
Operating system:
PHP version: Irrelevant
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Strings variable parsing - complex syntax
Description:
Strings variables parsing, as documented on
http://ca2.php.net/manual/en/language.types.string.php#language.types.string.parsing
is partly broken, or incorrectly documented.
The documentation says:
In fact, any value in the namespace can be included in a string with this
syntax. Simply write the expression the same way as it would appear outside
the string, and then wrap it in { and }.
But this seems to only work with pre-computed values accessible through
variables (using the dollar sign). This works neither for return values of
functions in the namespace, nor for constants.
BTW, in the examples, there is an extra backslash for the method example:
This is the value of the var named by the return value of
\$object->getName():
Test script:
---
http://bugs.php.net/bug.php?id=52897&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52897&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52897&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52897&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52897&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52897&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52897&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52897&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52897&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52897&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52897&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52897&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52897&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52897&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52897&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52897&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52897&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52897&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52897&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52897&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52897&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52897&r=mysqlcfg
[PHP-BUG] Bug #54049 [NEW]: output_buffering enabled by default in development configuration
From: Operating system: PHP version: 5.3.5 Package: *Configuration Issues Bug Type: Bug Bug description:output_buffering enabled by default in development configuration Description: output_buffering is Off by default, but not with the development profile: ; output_buffering ; Default Value: Off ; Development Value: 4096 ; Production Value: 4096 I understand why output buffering is enabled in production, however I can't see a reason why it would be disabled by default but enabled in development. I haven't found any rationale for this situation, but my impression is that this is a bug. -- Edit bug report at http://bugs.php.net/bug.php?id=54049&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54049&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54049&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54049&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54049&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54049&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54049&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54049&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54049&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54049&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54049&r=support Expected behavior: http://bugs.php.net/fix.php?id=54049&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54049&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54049&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54049&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54049&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54049&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54049&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54049&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54049&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54049&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54049&r=mysqlcfg
[PHP-BUG] Bug #54051 [NEW]: output_buffering boolean values not interpreted correctly
From: Operating system: Debian GNU/Linux PHP version: Irrelevant Package: PHP options/info functions Bug Type: Bug Bug description:output_buffering boolean values not interpreted correctly Description: As reported in http://bugs.php.net/bug.php?id=29575 phpinfo() displays the value of output_buffering as "no value" instead of Off when it is set to Off. output_buffering is supposed to support boolean values: ; Output buffering is a mechanism for controlling how much output data ; (excluding headers and cookies) PHP should keep internally before pushing that ; data to the client. If your application's output exceeds this setting, PHP ; will send that data in chunks of roughly the size you specify. ; Turning on this setting and managing its maximum buffer size can yield some ; interesting side-effects depending on your application and web server. ; You may be able to send headers and cookies after you've already sent output ; through print or echo. You also may see performance benefits if your server is ; emitting less packets due to buffered output versus PHP streaming the output ; as it gets it. On production servers, 4096 bytes is a good setting for performance ; reasons. ; Note: Output buffering can also be controlled via Output Buffering Control ; functions. ; Possible Values: ; On = Enabled and buffer is unlimited. (Use with caution) ; Off = Disabled ; Integer = Enables the buffer and sets its maximum size in bytes. ; Note: This directive is hardcoded to Off for the CLI SAPI ; Default Value: Off ; Development Value: 4096 ; Production Value: 4096 ; http://php.net/output-buffering But if it is set to Off, its value becomes an empty string. If it is set to On, its value becomes 1. I set the version to Irrelevant so the system would let me submit the report, but the version I verified this on is PHP 5.3.3. -- Edit bug report at http://bugs.php.net/bug.php?id=54051&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54051&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54051&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54051&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54051&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54051&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54051&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54051&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54051&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54051&r=support Expected behavior: http://bugs.php.net/fix.php?id=54051&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54051&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54051&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54051&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54051&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54051&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54051&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54051&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54051&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54051&r=mysqlcfg
Bug #29575 [Com]: output_buffering off doesn't show in phpinfo
Edit report at http://bugs.php.net/bug.php?id=29575&edit=1 ID: 29575 Comment by: chealer at gmail dot com Reported by:intreg at zoom dot co dot uk Summary:output_buffering off doesn't show in phpinfo Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Debian GNU/Linux PHP Version:4.3.8 Block user comment: N Private report: N New Comment: I opened a new ticket for this bug, see #54051. Previous Comments: [2004-08-12 22:41:16] intreg at zoom dot co dot uk I hope the summary is updated to what I wanted it to now be which is "output_buffering off doesn't show in phpinfo". This is only a minor quibble, so whoever next looks at the phpinfo section of the code might see why this is. I don't know enought C right now, but who knows, if it's still this way in php 6 then I might take it on then. [2004-08-12 07:00:54] mag...@php.net This sounds very much like you aren't editing the correct php.ini file. Check the phpinfo() output where it's looking for the php.ini file and put your edited file where it want it to be. [2004-08-09 09:35:06] intreg at zoom dot co dot uk went back to 4.3.7 and still same result - thinking perhaps the header messages (already sent) may not be as I first thought related to the output_buffering setting. Won't know for sure until I go back an apache version (2.0.50 to 2.0.49) and figure out which bit of the setup is producing my problem [will be doing another setup/build in two weeks]. I leave this minor bug report on file as php output_buffering setting would be easier to eliminate as a possible cause if my php.ini setting of 'off' could be seen in phpinfo as 'off'. [2004-08-08 21:34:06] intreg at zoom dot co dot uk Description: output_buffering = Off output_buffering=off tried both of these but phpinfo still seems to show 'no value' for this directive. If you want to see if anyone else has managed to successfully switch it off, then a quick browse through google using a search string as follows: output_buffering 4.3.8 off didn't produce any examples I could find [lots of 'no value' and 4096 and 0 but seemingly no 'off']. Just off to try making apache override the php setting, otherwise it's back to 4.3.7 [the web developer does his own flushing and I'm not about to tell him that he can no longer do this] Regards, Gary. -- Edit this bug report at http://bugs.php.net/bug.php?id=29575&edit=1
[PHP-BUG] Bug #54673 [NEW]: readdir(false) returns NULL
From: Operating system: PHP version: 5.3.6 Package: Directory function related Bug Type: Bug Bug description:readdir(false) returns NULL Description: According to http://php.net/readdir readdir "Returns the filename on success or FALSE on failure." As reported in #52383, since PHP 5.3 readdir may also return NULL on failure. The regression can be seen here: # php -r 'var_dump(phpversion(), @readdir(false), @readdir(false)===false);' string(8) "5.2.11-2" bool(false) bool(true) $ php -r 'var_dump(phpversion(), @readdir(false), @readdir(false)===false);' string(8) "5.3.6-10" NULL bool(false) According to the first bullet on http://php.net/manual/en/migration53.incompatible.php this would be an intentional change, so this would be a documentation bug. Test script: --- var_dump(@readdir(false)); Expected result: bool(false) Actual result: -- NULL -- Edit bug report at http://bugs.php.net/bug.php?id=54673&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54673&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54673&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54673&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54673&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54673&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54673&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54673&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54673&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54673&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54673&r=support Expected behavior: http://bugs.php.net/fix.php?id=54673&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54673&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54673&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54673&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54673&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54673&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54673&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54673&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54673&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54673&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54673&r=mysqlcfg
[PHP-BUG] Bug #55780 [NEW]: $_SERVER['REQUEST_URI'] does not contain the request's complete URI
From: Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:$_SERVER['REQUEST_URI'] does not contain the request's complete URI Description: According to http://www.php.net/manual/en/reserved.variables.server.php the REQUEST_URI entry of $_SERVER contains "The URI which was given in order to access this page". This is not the case, as the example given just after shows: "for instance, '/index.html'". Actually, REQUEST_URI contains a URI reference. This bug exists since as far as I can remember. At this point, it is probably a bad idea to simply fix. This should probably be treated as a documentation bug, and just cause the $_SERVER documentation to fix the entry description, adding a warning about the name. However, having the actual request URI would be useful too, be it through a new "ACTUAL_REQUEST_URI" entry, a function, or something. Note: this bug is not completely PHP-specific. http://labs.apache.org/webarch/uri/rfc/rfc3986.html#hierarchical gives a historical perspective on URI/URL terminology. -- Edit bug report at https://bugs.php.net/bug.php?id=55780&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55780&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55780&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55780&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55780&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55780&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55780&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55780&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55780&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55780&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55780&r=support Expected behavior: https://bugs.php.net/fix.php?id=55780&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55780&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55780&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55780&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55780&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55780&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55780&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55780&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55780&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55780&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55780&r=mysqlcfg
[PHP-BUG] Req #71677 [NEW]: Do not keep last element treated by foreach referenced
From: Operating system: PHP version: 5.3.8 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Do not keep last element treated by foreach referenced Description: As explained on http://ca.php.net/manual/en/control-structures.foreach.php : Warning Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset(). In my opinion, PHP shouldn't keep the last element referenced by default, but at least, please provide a syntax which will not keep it. The current situations causes bugs like https://bugs.php.net/bug.php?id=49386 -- Edit bug report at https://bugs.php.net/bug.php?id=71677&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=71677&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=71677&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=71677&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=71677&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=71677&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=71677&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=71677&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=71677&r=needscript Try newer version: https://bugs.php.net/fix.php?id=71677&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=71677&r=support Expected behavior: https://bugs.php.net/fix.php?id=71677&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=71677&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=71677&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=71677&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=71677&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=71677&r=dst IIS Stability: https://bugs.php.net/fix.php?id=71677&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=71677&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=71677&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=71677&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=71677&r=mysqlcfg
[PHP-BUG] Bug #60286 [NEW]: [FR] Wrong French translation of fgetcsv()'s description
From: Operating system: PHP version: Irrelevant Package: Translation problem Bug Type: Bug Bug description:[FR] Wrong French translation of fgetcsv()'s description Description: fgetcsv()'s description is "Gets line from file pointer and parse for CSV fields". This is translated to French as "Renvoie la ligne courante et cherche les champs CSV".fgetcsv() ne renvoie pas la ligne courante (it doesn't return the current line). It just "gets" it (I guess the English description could be simplified and just say "Parse the current line from a file pointer for CSV fields", which doesn't go into the implementation). I would translate the current description to "Obtient une ligne depuis un pointeur de fichier et l'analyse pour des champs CSV". -- Edit bug report at https://bugs.php.net/bug.php?id=60286&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60286&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60286&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60286&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60286&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60286&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60286&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60286&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60286&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60286&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60286&r=support Expected behavior: https://bugs.php.net/fix.php?id=60286&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60286&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60286&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60286&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60286&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60286&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60286&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60286&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60286&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60286&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60286&r=mysqlcfg
