Bug #61335 [Com]: Access to array node returns wrong truth value
Edit report at https://bugs.php.net/bug.php?id=61335edit=1 ID: 61335 Comment by: cschneid at cschneid dot com Reported by:mueller at relog dot ch Summary:Access to array node returns wrong truth value Status: Open Type: Bug Package:SimpleXML related Operating System: Linux PHP Version:5.4.0 Block user comment: N Private report: N New Comment: It seems commit 311171 broke it: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311171r2=311170pathrev=311171 Previous Comments: [2012-03-13 13:19:01] mueller at relog dot ch The other bug is said to have been fixed in svn, however my bug still happens in the current version from svn. [2012-03-10 00:00:29] me at ktamura dot com I think this bug is related to https://bugs.php.net/bug.php?id=51615 [2012-03-09 18:00:28] mueller at relog dot ch I forgot: Omitting the [0] array access will also fix the problem. [2012-03-09 17:57:50] mueller at relog dot ch Description: When accessing a simplexml node as array, I always get an empty simplexml object. If I cast the node to string, the behaviour is correct. If the parent node contains nothing but the child node (not even a newline) then the behaviour is also correct. Under php 5.3, the behaviour is correct. Test script: --- $rec1 = simplexml_load_string(foobaraa/bar\n/foo); $rec2 = simplexml_load_string(foobaraa/bar/foo); if ($rec1-bar[0]) echo NONEMPTY1\n; # not reached, bug if ($rec1-bar[0] . ) echo NONEMPTY2\n; # correct if ($rec2-bar[0]) echo NONEMPTY3\n; # correct Expected result: NONEMPTY1 NONEMPTY2 NONEMPTY3 Actual result: -- NONEMPTY2 NONEMPTY3 -- Edit this bug report at https://bugs.php.net/bug.php?id=61335edit=1
[PHP-BUG] Bug #51263 [NEW]: imagettftext and rotated text uses wrong baseline (regression)
From: Operating system: PHP version: 5.3.2 Package: GD related Bug Type: Bug Bug description:imagettftext and rotated text uses wrong baseline (regression) Description: imagettftext and rotated text by e.g. 90 degrees aligns text on top of characters instead of baseline. The regression was introduced with commit r293268 | tabe | 2010-01-08 13:18:52 | Bug #49600 (imageTTFText text shifted right) - fix difference of horizontal position between imagettftext() and imagettfbbox() Test script: --- ?php $img = imagecreatetruecolor(23, 100); $col = imagecolorallocate($img, 255, 255, 255); imagettftext($img, 8, 90, 10, 90, $col, verdana.ttf, foo bar qux); imagepng($img, img.png); Expected result: Normal text rotated by 90 degrees Actual result: -- Text rotated but aligned at top of characters instead of bottom -- Edit bug report at http://bugs.php.net/bug.php?id=51263edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51263r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51263r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51263r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51263r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51263r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51263r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51263r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51263r=needscript Try newer version: http://bugs.php.net/fix.php?id=51263r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51263r=support Expected behavior: http://bugs.php.net/fix.php?id=51263r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51263r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51263r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51263r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51263r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51263r=dst IIS Stability: http://bugs.php.net/fix.php?id=51263r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51263r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51263r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51263r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51263r=mysqlcfg
#49903 [NEW]: Strip $ at beginning of variable names for compact()
From: cschneid at cschneid dot com
Operating system:
PHP version: 6SVN-2009-10-16 (SVN)
PHP Bug Type: Feature/Change Request
Bug description: Strip $ at beginning of variable names for compact()
Description:
One reason we are not using compact() in our production code is that it is
hard to search for variable references because $foo is simply called 'foo'
in compact()
Suggestion: Strip off a leading $ before looking up variables, i.e. make
compact('$foo') equivalent to compact('foo').
It's clear that people can shoot themselves in the foot if they try
compact($foo) but it would possibly make code using compact() a little
easier to maintain.
Patch:
Index: ext/standard/array.c
===
--- ext/standard/array.c(revision 289696)
+++ ext/standard/array.c(working copy)
@@ -1488,7 +1488,7 @@
{
zstr key;
int key_len;
- zend_bool free_key = 0;
+ void *free_key = NULL;
zval **value_ptr, *value, *data;
if (Z_TYPE_P(entry) == IS_STRING || Z_TYPE_P(entry) == IS_UNICODE)
{
@@ -1505,9 +1505,19 @@
} else if (norm != key.u) {
key.u = norm;
key_len = norm_len;
- free_key = 1;
+ free_key = norm;
}
+ if (*key.u == '$') {
+ key.u++;
+ key_len--;
+ }
}
+ else {
+ if (*key.s == '$') {
+ key.s++;
+ key_len--;
+ }
+ }
if (zend_u_hash_find(eg_active_symbol_table,
Z_TYPE_P(entry), key, key_len + 1, (void **)value_ptr) != FAILURE) {
value = *value_ptr;
ALLOC_ZVAL(data);
@@ -1518,7 +1528,7 @@
zend_u_hash_update(Z_ARRVAL_P(return_value),
Z_TYPE_P(entry), key, key_len + 1, data, sizeof(zval *), NULL);
}
if (free_key) {
- efree(key.v);
+ efree(free_key);
}
}
else if (Z_TYPE_P(entry) == IS_ARRAY) {
Reproduce code:
---
sapi/cli/php -r '$foo = FOO; var_dump(compact(\$foo));'
Expected result:
array(1) {
[ufoo]=
unicode(3) FOO
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=49903edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49903r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49903r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49903r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49903r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49903r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49903r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49903r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49903r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49903r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49903r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49903r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49903r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49903r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49903r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49903r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49903r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49903r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49903r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49903r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49903r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49903r=mysqlcfg
#49819 [NEW]: STDOUT losing data with posix_isatty()
From: cschneid at cschneid dot com Operating system: PHP version: 6SVN-2009-10-09 (SVN) PHP Bug Type: Streams related Bug description: STDOUT losing data with posix_isatty() Description: The PHP streams for stdin, stdout and stderr are seekable which results in php_stream_flush() and seek being called on it. For some reason php_stream_flush() fails to actually write the data while still calling seek and resetting the stream position. Suggested solution: - Find out why php_stream_flush() fails and fix it (I don't know enough about it) - Mark (some? all?) stdio streams as PHP_STREAM_FLAG_NO_SEEK in sapi/cli/php_cli.c (see patch) - Mark stdio streams as PHP_STREAM_FLAG_NO_SEEK in ext/standard/php_fopen_wrapper.c Reproduce code: --- php -r 'echo hello1\n; posix_isatty(STDOUT); echo hello2\n;' out; cat out Expected result: hello1 hello2 Actual result: -- hello2 -- Edit bug report at http://bugs.php.net/?id=49819edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49819r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49819r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49819r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49819r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49819r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49819r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49819r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49819r=needscript Try newer version: http://bugs.php.net/fix.php?id=49819r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49819r=support Expected behavior: http://bugs.php.net/fix.php?id=49819r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49819r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49819r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49819r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49819r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49819r=dst IIS Stability: http://bugs.php.net/fix.php?id=49819r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49819r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49819r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49819r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49819r=mysqlcfg
#49819 [Opn]: STDOUT losing data with posix_isatty()
ID: 49819 User updated by: cschneid at cschneid dot com Reported By: cschneid at cschneid dot com Status: Open Bug Type:Streams related PHP Version: 6SVN-2009-10-09 (SVN) New Comment: --- sapi/cli/php_cli.c (revision 289412) +++ sapi/cli/php_cli.c (working copy) @@ -565,6 +565,10 @@ s_err-flags |= PHP_STREAM_FLAG_NO_CLOSE; #endif + s_in-flags |= PHP_STREAM_FLAG_NO_SEEK; + s_out-flags |= PHP_STREAM_FLAG_NO_SEEK; + s_err-flags |= PHP_STREAM_FLAG_NO_SEEK; + s_in_process = s_in; php_stream_to_zval(s_in, zin); Previous Comments: [2009-10-09 12:50:19] cschneid at cschneid dot com Description: The PHP streams for stdin, stdout and stderr are seekable which results in php_stream_flush() and seek being called on it. For some reason php_stream_flush() fails to actually write the data while still calling seek and resetting the stream position. Suggested solution: - Find out why php_stream_flush() fails and fix it (I don't know enough about it) - Mark (some? all?) stdio streams as PHP_STREAM_FLAG_NO_SEEK in sapi/cli/php_cli.c (see patch) - Mark stdio streams as PHP_STREAM_FLAG_NO_SEEK in ext/standard/php_fopen_wrapper.c Reproduce code: --- php -r 'echo hello1\n; posix_isatty(STDOUT); echo hello2\n;' out; cat out Expected result: hello1 hello2 Actual result: -- hello2 -- Edit this bug report at http://bugs.php.net/?id=49819edit=1
#45928 [Com]: large scripts from stdin are stripped at 16K border
ID: 45928 Comment by: cschneid at cschneid dot com Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: CGI related Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2008-08-26 (CVS) New Comment: I had a quick look at this bug and found the problem to be in Zend/zend_stream.c function zend_stream_fsize(): It uses fstat() to determine the filesize which on MacOS X for pipes returns either 0 (my interpretation: no data from the pipe ready yet) or a number up to 16384 (my interpretation: data from the pipe ready but the maximum buffer size is 16k). I see several solutions but I'm not sure which is the desired one: - return 0 (size unknown) if the file is a pipe (or socket, ...) - return 0 if the file is not a regular file (or symlink, dir?) - look into a way of determining EOF reached As a quick test I changed return buf.st_size; in function zend_stream_fsize() to return 0; and cat 30k.php | php worked after that. I posted this to [EMAIL PROTECTED] but did not get any reply so I'm not sure how to proceed. Previous Comments: [2008-08-26 18:24:52] [EMAIL PROTECTED] Description: any php-file which is larger that 16Kb will result in parse error on Mac OS X, if run as following: cat largefile.php|php -l while the following options will work: php -l largefile.php php -l largefile.php -l flag is optional. it can be reproduced without it too I discussed this with Rasmus (he was able to reproduce this problem too), and he mentioned, that this bug is most likely re2c-related Expected result: No syntax errors detected in - Actual result: -- PHP Parse error: syntax error, unexpected $end in -- Edit this bug report at http://bugs.php.net/?id=45928edit=1
#44533 [NEW]: floatval() issues E_NOTICE non well formed numeric value
From: cschneid at cschneid dot com Operating system: PHP version: 6CVS-2008-03-25 (CVS) PHP Bug Type: Unknown/Other Function Bug description: floatval() issues E_NOTICE non well formed numeric value Description: floatval(4foo); issues E_NOTICE non well formed numeric value Reproduce code: --- php -d error_reporting=65535 -r 'var_dump(floatval(4foo));' Expected result: float(4) Actual result: -- Notice: A non well formed numeric value encountered in Command line code on line 1 float(4) -- Edit bug report at http://bugs.php.net/?id=44533edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44533r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44533r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44533r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44533r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44533r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44533r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44533r=needscript Try newer version:http://bugs.php.net/fix.php?id=44533r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44533r=support Expected behavior:http://bugs.php.net/fix.php?id=44533r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44533r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44533r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44533r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44533r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44533r=dst IIS Stability:http://bugs.php.net/fix.php?id=44533r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44533r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44533r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44533r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44533r=mysqlcfg
#41315 [NEW]: file() should support FILE_SKIP_EMPTY_LINES without FILE_IGNORE_NEW_LINES
From: cschneid at cschneid dot com
Operating system:
PHP version: 5.2.2
PHP Bug Type: Feature/Change Request
Bug description: file() should support FILE_SKIP_EMPTY_LINES without
FILE_IGNORE_NEW_LINES
Description:
Currently file() only skips (FILE_SKIP_EMPTY_LINES) when also using
FILE_IGNORE_NEW_LINES at the same time. I think it would be
preferable if it would work without that flag too, ignoring lines
only consisting of a newline.
Patch
diff -u -r1.409.2.6.2.17 file.c
--- ext/standard/file.c 23 Feb 2007 16:22:20 -
1.409.2.6.2.17
+++ ext/standard/file.c 7 May 2007 16:17:27 -
@@ -750,6 +750,10 @@
do {
p++;
parse_eol:
+ if (skip_blank_lines (p-s == 1)
(*s == eol_marker)) {
+ s = p;
+ continue;
+ }
if (PG(magic_quotes_runtime)) {
/* s is in target_buf which
is freed at the end of the function */
slashed = php_addslashes(s,
(p-s), len, 0 TSRMLS_CC);
Reproduce code:
---
Input file x:
a
b
Code:
var_dump(file(x, FILE_SKIP_EMPTY_LINES));
Expected result:
a
b
Actual result:
--
a
b
--
Edit bug report at http://bugs.php.net/?id=41315edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41315r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41315r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41315r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41315r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41315r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41315r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41315r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41315r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41315r=support
Expected behavior:http://bugs.php.net/fix.php?id=41315r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41315r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41315r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41315r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41315r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41315r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41315r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41315r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41315r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41315r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41315r=mysqlcfg
#25547 [Ver]: error_handler and array index with function call
ID: 25547
User updated by: cschneid at cschneid dot com
Reported By: cschneid at cschneid dot com
Status: Verified
-Bug Type: Zend Engine 2 problem
+Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS
New Comment:
Problem still exists in PHP4 branch
Previous Comments:
[2003-12-31 03:17:39] [EMAIL PROTECTED]
The bug is fixed in PHP5 CVS (zend.c,v 1.260).
[2003-10-16 04:09:39] [EMAIL PROTECTED]
You now have a memory leak. I tried something similar too. But we
decided to look for a better solution where we don't gc the variable we
still need.
[2003-10-15 08:19:08] cschneid at cschneid dot com
The problem seems to be that dim-value is overwritten, copying the
value solves this. I don't have enough insight in Zend to know if this
is a memory leak and the values should be freed at some point or if
this is ok.
Hope this helps:
diff -u -u -r1.316.2.21 zend_execute.c
--- Zend/zend_execute.c 30 Jul 2003 16:33:54 - 1.316.2.21
+++ Zend/zend_execute.c 15 Oct 2003 12:17:10 -
@@ -626,7 +626,7 @@
offset_key_length = 0;
goto fetch_string_dim;
case IS_STRING:
- offset_key = dim-value.str.val;
+ offset_key = estrndup(dim-value.str.val,
dim-value.str.len);
offset_key_length = dim-value.str.len;
fetch_string_dim:
[2003-09-15 13:37:55] cschneid at cschneid dot com
Description:
Error handler seems to destroy array indices if called due
to a undefined array index generated by a function.
Reproduce code:
---
function handler($errno, $errstr, $errfile, $errline)
{
$test = aaa;
}
set_error_handler('handler');
$output[trim(bbb)]++;
print_r($output);
Expected result:
Array
(
[bbb] = 1
)
Actual result:
--
Array
(
[aaa] = 1
)
--
Edit this bug report at http://bugs.php.net/?id=25547edit=1
#25547 [Ver]: error_handler and array index with function call
ID: 25547
User updated by: cschneid at cschneid dot com
Reported By: cschneid at cschneid dot com
Status: Verified
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS
New Comment:
A workaround patch (without memory leak ;-)) can be found at
http://cschneid.com/php/php4/bug25547.patch
Previous Comments:
[2004-01-04 17:49:09] cschneid at cschneid dot com
Problem still exists in PHP4 branch
[2003-12-31 03:17:39] [EMAIL PROTECTED]
The bug is fixed in PHP5 CVS (zend.c,v 1.260).
[2003-10-16 04:09:39] [EMAIL PROTECTED]
You now have a memory leak. I tried something similar too. But we
decided to look for a better solution where we don't gc the variable we
still need.
[2003-10-15 08:19:08] cschneid at cschneid dot com
The problem seems to be that dim-value is overwritten, copying the
value solves this. I don't have enough insight in Zend to know if this
is a memory leak and the values should be freed at some point or if
this is ok.
Hope this helps:
diff -u -u -r1.316.2.21 zend_execute.c
--- Zend/zend_execute.c 30 Jul 2003 16:33:54 - 1.316.2.21
+++ Zend/zend_execute.c 15 Oct 2003 12:17:10 -
@@ -626,7 +626,7 @@
offset_key_length = 0;
goto fetch_string_dim;
case IS_STRING:
- offset_key = dim-value.str.val;
+ offset_key = estrndup(dim-value.str.val,
dim-value.str.len);
offset_key_length = dim-value.str.len;
fetch_string_dim:
[2003-09-15 13:37:55] cschneid at cschneid dot com
Description:
Error handler seems to destroy array indices if called due
to a undefined array index generated by a function.
Reproduce code:
---
function handler($errno, $errstr, $errfile, $errline)
{
$test = aaa;
}
set_error_handler('handler');
$output[trim(bbb)]++;
print_r($output);
Expected result:
Array
(
[bbb] = 1
)
Actual result:
--
Array
(
[aaa] = 1
)
--
Edit this bug report at http://bugs.php.net/?id=25547edit=1
#25547 [Asn]: error_handler and array index with function call
ID: 25547
User updated by: cschneid at cschneid dot com
Reported By: cschneid at cschneid dot com
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS
Assigned To: helly
New Comment:
The problem seems to be that dim-value is overwritten, copying the
value solves this. I don't have enough insight in Zend to know if this
is a memory leak and the values should be freed at some point or if
this is ok.
Hope this helps:
diff -u -u -r1.316.2.21 zend_execute.c
--- Zend/zend_execute.c 30 Jul 2003 16:33:54 - 1.316.2.21
+++ Zend/zend_execute.c 15 Oct 2003 12:17:10 -
@@ -626,7 +626,7 @@
offset_key_length = 0;
goto fetch_string_dim;
case IS_STRING:
- offset_key = dim-value.str.val;
+ offset_key = estrndup(dim-value.str.val,
dim-value.str.len);
offset_key_length = dim-value.str.len;
fetch_string_dim:
Previous Comments:
[2003-09-15 13:37:55] cschneid at cschneid dot com
Description:
Error handler seems to destroy array indices if called due
to a undefined array index generated by a function.
Reproduce code:
---
function handler($errno, $errstr, $errfile, $errline)
{
$test = aaa;
}
set_error_handler('handler');
$output[trim(bbb)]++;
print_r($output);
Expected result:
Array
(
[bbb] = 1
)
Actual result:
--
Array
(
[aaa] = 1
)
--
Edit this bug report at http://bugs.php.net/?id=25547edit=1
#25547 [NEW]: error_handler and array index with function call
From: cschneid at cschneid dot com
Operating system: Linux
PHP version: Irrelevant
PHP Bug Type: Scripting Engine problem
Bug description: error_handler and array index with function call
Description:
Error handler seems to destroy array indices if called due
to a undefined array index generated by a function.
Reproduce code:
---
function handler($errno, $errstr, $errfile, $errline)
{
$test = aaa;
}
set_error_handler('handler');
$output[trim(bbb)]++;
print_r($output);
Expected result:
Array
(
[bbb] = 1
)
Actual result:
--
Array
(
[aaa] = 1
)
--
Edit bug report at http://bugs.php.net/?id=25547edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25547r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25547r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25547r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25547r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25547r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25547r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25547r=support
Expected behavior: http://bugs.php.net/fix.php?id=25547r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25547r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25547r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25547r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25547r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25547r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25547r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25547r=gnused
