#36240 [NEW]: foreach($arr as $k => &$v) corrupts array on second iteration
From: dshadow at zort dot net Operating system: Mac OS X PHP version: 5.1.2 PHP Bug Type: Scripting Engine problem Bug description: foreach($arr as $k => &$v) corrupts array on second iteration Description: After using foreach($arr as $k => &$v) to modify the $arr, iterating again using the same variable $v causes the array to be altered unexpectedly. Adding an unset($v) between the two foreach loops, or using a different variable on the second foreach loop works around the problem. Reproduce code: --- 1, 'two' => 2, 'three' => 3, ); foreach($arr as $k => &$v) if($v == 1) $v = 'meh'; print_r($arr); foreach($arr as $k => $v) ; print_r($arr); Expected result: The code above should not cause the $arr to be modified by running the second foreach loop. Actual result: -- The code above outputs the following: Array ( [one] => meh [two] => 2 [three] => 3 ) Array ( [one] => meh [two] => 2 [three] => 2 ) -- Edit bug report at http://bugs.php.net/?id=36240&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36240&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36240&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36240&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36240&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36240&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36240&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36240&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36240&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36240&r=support Expected behavior:http://bugs.php.net/fix.php?id=36240&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36240&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36240&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36240&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36240&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36240&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36240&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36240&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36240&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36240&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36240&r=mysqlcfg
#16330 [Opn]: There is no E_NONE constant. Patch included.
ID: 16330
User updated by: dshadow at zort dot net
Reported By: dshadow at zort dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 4.1.2
New Comment:
Because having E_NONE is consistent. Then any possible
value you might want to pass to error_reporting() has a
symbolic constant. Sure, "0" conceptually means "none",
but there's no reason that the value 0 MUST mean "no
errors". It just happens to be true in this case.
I'll agree that this may not be a compelling reason to
include E_NONE, but, I can't think of any compelling
reason why _NOT_ to include it, especially considering
that this is a two line patch that is not invasive at
all.
Also, the documentation references E_NONE, so at
least one other person feels it to be a reasonable
constant, so much that they didn't check to make sure
that the constant actually existed:
http://us3.php.net/security.errors
Previous Comments:
[2004-04-26 09:13:57] jevon at jevon dot org
This makes no sense. Why have E_NONE when using '0' is simpler? I don't
see how it would be helpful at all, especially since 0 is not a
combination of any other numbers.
--------
[2002-03-28 10:43:36] dshadow at zort dot net
While investigating bug 16004, I noticed there is no E_NONE error
constant. The folowing patch provides one. (Apologies if this is
mangled, but I don't see another way to submit patches...)
diff -ur php-4.1.2/Zend/zend_constants.c
php-4.1.2-enone/Zend/zend_constants.c
--- php-4.1.2/Zend/zend_constants.c Mon Dec 17 00:22:24 2001
+++ php-4.1.2-enone/Zend/zend_constants.c Thu Mar 28 10:32:06 2002
@@ -102,6 +102,8 @@
void zend_register_standard_constants(TSRMLS_D)
{
+ REGISTER_MAIN_LONG_CONSTANT("E_NONE", E_NONE, CONST_PERSISTENT |
CONST_CS);
+
REGISTER_MAIN_LONG_CONSTANT("E_ERROR", E_ERROR, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_LONG_CONSTANT("E_WARNING", E_WARNING, CONST_PERSISTENT
| CONST_CS);
REGISTER_MAIN_LONG_CONSTANT("E_PARSE", E_PARSE, CONST_PERSISTENT |
CONST_CS);
diff -ur php-4.1.2/Zend/zend_errors.h
php-4.1.2-enone/Zend/zend_errors.h
--- php-4.1.2/Zend/zend_errors.hMon Dec 17 00:22:24 2001
+++ php-4.1.2-enone/Zend/zend_errors.h Thu Mar 28 10:31:41 2002
@@ -21,6 +21,8 @@
#ifndef ZEND_ERRORS_H
#define ZEND_ERRORS_H
+#define E_NONE (0)
+
#define E_ERROR(1<<0L)
#define E_WARNING (1<<1L)
#define E_PARSE(1<<2L)
--
Edit this bug report at http://bugs.php.net/?id=16330&edit=1
Bug #16330: There is no E_NONE constant. Patch included.
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.1.2
PHP Bug Type: Feature/Change Request
Bug description: There is no E_NONE constant. Patch included.
While investigating bug 16004, I noticed there is no E_NONE error constant.
The folowing patch provides one. (Apologies if this is mangled, but I
don't see another way to submit patches...)
diff -ur php-4.1.2/Zend/zend_constants.c
php-4.1.2-enone/Zend/zend_constants.c
--- php-4.1.2/Zend/zend_constants.c Mon Dec 17 00:22:24 2001
+++ php-4.1.2-enone/Zend/zend_constants.c Thu Mar 28 10:32:06 2002
@@ -102,6 +102,8 @@
void zend_register_standard_constants(TSRMLS_D)
{
+ REGISTER_MAIN_LONG_CONSTANT("E_NONE", E_NONE, CONST_PERSISTENT |
CONST_CS);
+
REGISTER_MAIN_LONG_CONSTANT("E_ERROR", E_ERROR, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_LONG_CONSTANT("E_WARNING", E_WARNING, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_LONG_CONSTANT("E_PARSE", E_PARSE, CONST_PERSISTENT |
CONST_CS);
diff -ur php-4.1.2/Zend/zend_errors.h php-4.1.2-enone/Zend/zend_errors.h
--- php-4.1.2/Zend/zend_errors.hMon Dec 17 00:22:24 2001
+++ php-4.1.2-enone/Zend/zend_errors.h Thu Mar 28 10:31:41 2002
@@ -21,6 +21,8 @@
#ifndef ZEND_ERRORS_H
#define ZEND_ERRORS_H
+#define E_NONE (0)
+
#define E_ERROR(1<<0L)
#define E_WARNING (1<<1L)
#define E_PARSE(1<<2L)
--
Edit bug report at http://bugs.php.net/?id=16330&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16330&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16330&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16330&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16330&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16330&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16330&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16330&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16330&r=submittedtwice
Bug #16004 Updated: @imap_msgno() and @imap_header() display warnings
ID: 16004 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 4.1.2 New Comment: Actually, it's slightly more complex than I thought: if I bracket the line giving the errors with $__old_err = error_reporting(0); ... error_reporting($__old_err); I still get the error output. If, however, I leave error_reporting disabled through script completion, the errors are supressed. Some additional testing reveals that if I simply put an error_reporting(0) at the very end of the script, then the errors are not displayed, regardless of there being @'s in fromt of imap_header() and/or imap_msgno(). But other warnings (like accessing undefined variables) are still thrown. Previous Comments: [2002-03-28 09:59:33] [EMAIL PROTECTED] E_NONE just doesn't exist :) [2002-03-28 09:44:32] [EMAIL PROTECTED] Putting error_reporting(0) supresses the errors. I can use this temporarially, but it's not an effective long-term solution. E_NONE does not seem to be defined! Should I file a separate bug for this? [2002-03-27 19:41:48] [EMAIL PROTECTED] Afaik this is related to how the current error handling in the ext/imap extension is implemented. Can you try settings error_reporting(E_NONE); _before_ you call the function in question and see if it does not output the error message? [2002-03-27 19:20:31] [EMAIL PROTECTED] I'm not sure; I will check tomorrow when I have access to the server and post another followup. The problem, isn't the error, though. The problem is that putting the @ infront of imap_msgno() and imap_header() _should_ supress the error output, and it is not. The error should not be appearing, but it is. [2002-03-27 18:02:21] [EMAIL PROTECTED] This error comes from c-client itself. What version you have compiled PHP with? 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 http://bugs.php.net/16004 -- Edit this bug report at http://bugs.php.net/?id=16004&edit=1
Bug #16004 Updated: @imap_msgno() and @imap_header() display warnings
ID: 16004 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 4.1.2 New Comment: Putting error_reporting(0) supresses the errors. I can use this temporarially, but it's not an effective long-term solution. E_NONE does not seem to be defined! Should I file a separate bug for this? Previous Comments: [2002-03-27 19:41:48] [EMAIL PROTECTED] Afaik this is related to how the current error handling in the ext/imap extension is implemented. Can you try settings error_reporting(E_NONE); _before_ you call the function in question and see if it does not output the error message? [2002-03-27 19:20:31] [EMAIL PROTECTED] I'm not sure; I will check tomorrow when I have access to the server and post another followup. The problem, isn't the error, though. The problem is that putting the @ infront of imap_msgno() and imap_header() _should_ supress the error output, and it is not. The error should not be appearing, but it is. [2002-03-27 18:02:21] [EMAIL PROTECTED] This error comes from c-client itself. What version you have compiled PHP with? [2002-03-11 16:24:09] [EMAIL PROTECTED] When processing an email with a header of 'To: ""<>', imap_msgno() and imap_header give errors of "Unexpected characters at end of address: <> (errflg=3) in Unknown on line 0", even when I call the functions with an @ preceding the function name to surpress error output. -- Edit this bug report at http://bugs.php.net/?id=16004&edit=1
Bug #16004 Updated: @imap_msgno() and @imap_header() display warnings
ID: 16004 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Linux PHP Version: 4.1.2 New Comment: I'm not sure; I will check tomorrow when I have access to the server and post another followup. The problem, isn't the error, though. The problem is that putting the @ infront of imap_msgno() and imap_header() _should_ supress the error output, and it is not. The error should not be appearing, but it is. Previous Comments: [2002-03-27 18:02:21] [EMAIL PROTECTED] This error comes from c-client itself. What version you have compiled PHP with? [2002-03-11 16:24:09] [EMAIL PROTECTED] When processing an email with a header of 'To: ""<>', imap_msgno() and imap_header give errors of "Unexpected characters at end of address: <> (errflg=3) in Unknown on line 0", even when I call the functions with an @ preceding the function name to surpress error output. -- Edit this bug report at http://bugs.php.net/?id=16004&edit=1
Bug #16265: Multiply-defined functions in classes not reported
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: Multiply-defined functions in classes not reported PHP does not report multiply-defined errors for class member functions. For example, the following script below, when executed, only outputs "two", with no errors. Instead, PHP should be giving error messages since the function bar has been defined multiple times. bar(); -- Edit bug report at http://bugs.php.net/?id=16265&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16265&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16265&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16265&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16265&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16265&r=support Expected behavior: http://bugs.php.net/fix.php?id=16265&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16265&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16265&r=submittedtwice
Bug #16004: @imap_msgno() and @imap_header() display warnings
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: IMAP related Bug description: @imap_msgno() and @imap_header() display warnings When processing an email with a header of 'To: ""<>', imap_msgno() and imap_header give errors of "Unexpected characters at end of address: <> (errflg=3) in Unknown on line 0", even when I call the functions with an @ preceding the function name to surpress error output. -- Edit bug report at http://bugs.php.net/?id=16004&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16004&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16004&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16004&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16004&r=support Expected behavior: http://bugs.php.net/fix.php?id=16004&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16004&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16004&r=submittedtwice
