#41528 [Asn->Csd]: Classes extending ArrayObject do not serialize correctly
ID: 41528
Updated by: [EMAIL PROTECTED]
Reported By: m dot stach at ewerk dot com
-Status: Assigned
+Status: Closed
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.*
Assigned To: davidc
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-12-06 16:06:49] [EMAIL PROTECTED]
There is a fix for it in 5.3.0 that needs a few tweaks, you can test it
for your usage already though. Assigning to david to do the tweaking.
[2007-08-05 15:31:25] pcdinh at gmail dot com
This bug remain still on PHP 5.2.4RC1
[2007-05-29 10:48:09] m dot stach at ewerk dot com
Description:
If a class extends ArrayObject, serializing does not work correctly.
All properties are missing after unserializing, only the array contents
are remain.
ArrayObjects (un)serializes without problems and does not implement the
Serializable interface, so there seems no need to change the
implementation of that interface.
The documentation mentions that it is not possible to serialize objects
of internal class. Since ArrayObject itself serializes fine, I regard
ArrayObject as "non-internal".
May be this is a documentation bug. But this would IMHO limit the broad
use of the ArrayObject class.
Reproduce code:
---
class a extends ArrayObject {
public $a = 2;
}
$a = new a();
$a->a = 1;
var_dump($a);
var_dump($a->a);
$a = unserialize(serialize($a));
var_dump($a);
var_dump($a->a);
Expected result:
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
Actual result:
--
object(a)#1 (0) { }
int(1)
object(a)#2 (0) { }
int(2)
--
Edit this bug report at http://bugs.php.net/?id=41528&edit=1
#43450 [Opn]: Memory leak on some functions with implicit object __toString() call
ID: 43450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.5
New Comment:
Patches are added for 5_2, 5_3 and HEAD there:
http://dev.agoraproduction.com/php/Zend/
Thanks,
Previous Comments:
[2007-12-20 11:47:59] [EMAIL PROTECTED]
It appears that zend_std_cast_object_tostring() does not check whether
it has to dref readobj prior writing to writeobj in case they are the
same zval.
That said the code needs to be refactored to:
- if (readobj==writeobj) { zval_dtor(readobj); } // not zval_ptr_dtor
- call INIT_PZVAL(writeobj) always
- set Z_TYPE_P(writeobj) = IS_NULL; for the default case
[2007-11-30 01:34:56] [EMAIL PROTECTED]
I'm still not sure if this has anything to do with the new Zend parsing
API, but I've tested the md5 function with the zend_get_parameters_ex
(the old API) and the leak didn't occur. See the two version for a
comparison.
currently
PHP_NAMED_FUNCTION(php_if_md5)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"s|b", &arg, &arg_len, &raw_output) == FAILURE) {
return;
}
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, arg, arg_len);
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
--- hacked rewrite
PHP_NAMED_FUNCTION(php_if_md5)
{
zval **zarg;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (ZEND_NUM_ARGS() != 1 ||
zend_get_parameters_ex(1, &zarg) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(zarg);
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, Z_STRVAL_PP(zarg), Z_STRLEN_PP(zarg));
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
[2007-11-29 14:59:48] [EMAIL PROTECTED]
Description:
Under certain circumenstances, the implicit call to __toString() on an
object may lead to memory leaks.
In the reproducable example, the following line leaks ($o is a simply
object):
md5($o);
But this line doesn't:
md5($o->__toString());
This only applies to certain functions, I've identifier md5, sha1 and
crc32.
If I try other examples like strstr or strlen, there's no leak at all.
A wild guess is that this maybe has to do whether the function
internally uses zend_parse_parameters() or zend_get_parameters_ex().
The function which leak use zend_parse_parameters(), the others don't.
But this may completely accidental.
It seems very related to bug#38591. However I don't see how bug#38604
is related to this issue (mentioned in bug#38591).
This leak was most notable found in an application which is supposed to
run for a long time, even hours. So usually within web application this
is not an issue.
Reproduce code:
---
__toString());
# does not leak either way
# strstr($o, 'f');
#strstr($o->__toString(), 'f');
if ($i % 1e3 == 0) {
printf("%u: %1.2f KB\n",
$i, memory_get_usage(true) / 1024);
}
}
Expected result:
Constant memory usage.
Actual result:
--
Memory grows and grows.
--
Edit this bug report at http://bugs.php.net/?id=43450&edit=1
#43908 [Opn]: exec() swallows whitespace in output
ID: 43908 Updated by: [EMAIL PROTECTED] Reported By: Arne dot Heizmann at csr dot com Status: Open Bug Type: *General Issues Operating System: Windows 2000 PHP Version: 5.2.5 New Comment: Even easier to reproduce: Previous Comments: [2008-01-22 16:51:56] Arne dot Heizmann at csr dot com Description: The exec() call is supposed to return the output of the system call into the second parameter. However, it modifies this output. It behaves as if rtrim() is called on each line. This causes data loss because rtrim() is not reversible. Reproduce code: --- Expected result: array ( 0 => ' ', ) Actual result: -- array ( 0 => '', ) -- Edit this bug report at http://bugs.php.net/?id=43908&edit=1
#36391 [Opn]: $a[] doesn't work correctly after array_pop
ID: 36391
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: WinXP
PHP Version: 5.1.2
New Comment:
This is expected behavior. Workaround you "could" do is:
'd');
array_pop($array);
array_pop($array);
$new = $array;
$new[] = 'd';
$array[] = 'd';
var_dump($new);
var_dump($array);
?>
That way you'll have your 1,2,3 keys in $new and the correctly indexed
array in $array.
"Note that the maximum integer key used for this need not currently
exist in the array. It simply must have existed in the array at some
time since the last time the array was re-indexed. The following example
illustrates: .." (You can see this link at:
http://ie.php.net/types.array)
Previous Comments:
[2008-01-28 14:43:37] [EMAIL PROTECTED]
Since there is no special notes in docs about this issue, it seems to
be a feature request, but still reasonable with array manipulation
formalizations.
[2008-01-28 14:42:13] [EMAIL PROTECTED]
--- php-5.2.5/ext/standard/array.c 2007-11-06 11:28:21.0 -0200
+++ /usr/local/src/php-5.2.5/ext/standard/array.c 2008-01-28
06:35:34.0 -0200
@@ -1994,7 +1994,7 @@
**val; /* Value to be popped */
char *key = NULL;
int key_len = 0;
- ulong index;
+ ulong index, new_index = 0;
/* Get the arguments and do error-checking */
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &stack) ==
FAILURE) {
@@ -2048,6 +2048,10 @@
}
} else if (!key_len && index >=
Z_ARRVAL_PP(stack)->nNextFreeElement-1) {
Z_ARRVAL_PP(stack)->nNextFreeElement =
Z_ARRVAL_PP(stack)->nNextFreeElement - 1;
+ } else if (!key_len && index <
Z_ARRVAL_PP(stack)->nNextFreeElement-1) {
+ zend_hash_internal_pointer_end(Z_ARRVAL_PP(stack));
+zend_hash_get_current_key_ex(Z_ARRVAL_PP(stack),
&key, &key_len, &new_index, 0, NULL);
+Z_ARRVAL_PP(stack)->nNextFreeElement = new_index +
1;
}
zend_hash_internal_pointer_reset(Z_ARRVAL_PP(stack));
[2006-02-14 17:33:38] tomas_matousek at hotmail dot com
Description:
Operator $a[] doesn't add a correct key to the array if applied after
popping from array. It seems array_pop merely checks whether the removed
index is the max. int key remembered by the array and if yes it
decreases it by 1. I would expect array_pop to find the new maximal key
in the resulting array.
Reproduce code:
---
$a = array("a","b",100 => "c",200 => "d");
array_pop($a);
array_pop($a);
$a[] = "new";
var_dump($a);
Expected result:
array(3) {
[0]=>
string(1) "a"
[1]=>
string(1) "b"
[2]=>
string(3) "new"
}
Actual result:
--
array(3) {
[0]=>
string(1) "a"
[1]=>
string(1) "b"
[199]=>
string(3) "new"
}
--
Edit this bug report at http://bugs.php.net/?id=36391&edit=1
#43947 [Opn]: mysql_select_db fails to select database using variables
ID: 43947 Updated by: [EMAIL PROTECTED] Reported By: joel dot a dot villarreal at gmail dot com Status: Open Bug Type: MySQL related Operating System: Windows XP Service Pack 2 PHP Version: 5.2.5 New Comment: What do you get if you do: echo $MySQL_DatabaseName . PHP_EOL; right after your connect() ? Previous Comments: [2008-01-27 22:40:01] joel dot a dot villarreal at gmail dot com Just in case, these are the versions of the server components being used at the moment: PHP Version 5.2.5 MySQL 5.0.46 Apaache 2.2.6 [2008-01-27 22:38:14] joel dot a dot villarreal at gmail dot com Description: When calling a function to connect to MySQL, while supplying a database name for mysql_select_db() through a variable defined at an include file, the database is not selected. Reproduce code: --- ## connection.cfg.php says: ## main.php says: Expected result: Expected result is to obtain a view of the row's data through the print_r() function. Actual result: -- mysql_error() prints: "No database selected". PHP warns mysql_fetch_array() has been given an invalid MySQL result resource. -- Edit this bug report at http://bugs.php.net/?id=43947&edit=1
#44153 [Opn]: PDO->errorCode() returns '' instead of SQLSTATE if no operation has been run
ID: 44153
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
New Comment:
What about returning NULL ? You could easily check the results using
is_null() and if it's null that means there's no errorCode().
Whereas when there's an error code you'll get the usual sqlstate
message/code.
What do you think? I think NULL would make great sense.
Previous Comments:
[2008-02-18 18:07:53] uwendel at mysql dot com
Description:
The PHP manual states that PDO->errorCode() returns the SQLSTATE
associated with the last operation run on the handle,
http://www.php.net/manual/en/function.PDO-errorCode.php
"Return Values
Returns a SQLSTATE, a five-character alphanumeric identifier defined in
the ANSI SQL-92 standard. Briefly, an SQLSTATE consists of a
two-character class value followed by a three-character subclass value.
A class value of 01 indicates a warning and is accompanied by a return
code of SQL_SUCCESS_WITH_INFO. Class values other than '01', except for
the class 'IM', indicate an error. The class 'IM' is specific to
warnings and errors that derive from the implementation of PDO (or
perhaps ODBC, if you're using the ODBC driver) itself. The subclass
value '000' in any class indicates that there is no subclass for that
SQLSTATE. "
What is PDO->errorCode() supposed to return if no operation has been
run on the handle yet?
If its valid to return any empty string, please add this to the
documentation.
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
var_dump($pdo->errorCode());'
string(0) ""
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());'
string(0) ""
Expected result:
Its a matter of taste. Personally I have a preference for returning
'0' as this makes checking the error code easier but this would be
sort of a BC break.
Actual result:
--
Empty string (see above).
--
Edit this bug report at http://bugs.php.net/?id=44153&edit=1
#44154 [Opn]: PDO->errorInfo() does not always return three element array
ID: 44154
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
New Comment:
I have a very small patch that I could commit if someone else agrees.
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44154.patch
Previous Comments:
[2008-02-18 18:25:09] uwendel at mysql dot com
Description:
According to the manual one can expect PDO->errorInfo() to return an
array with three elements.
"Return Values
PDO->errorInfo() returns an array of error information about the last
operation performed by this database handle. The array consists of the
following fields:
Element Information
0 SQLSTATE error code (a five-character alphanumeric identifier
defined in the ANSI SQL standard).
1 Driver-specific error code.
2 Driver-specific error message."
http://www.php.net/manual/en/function.PDO-errorInfo.php
The manual is wrong. PDO will not always return an array with three
elements. There are two situations when you will get an array with only
one element.
1) driver has not set an error code yet
2) IM001 - not implemented (= driver can't set an error code)
I'd appreciate if you either document this or fix PDO->errorInfo() to
always return an array with three elements. My personal preference is
change PDO->errorInfo(). I don't see any reason why people would have to
use a complicated test like the following to avoid "undefined index"
style messages:
if (count($info = $pdo->errorInfo()) == 3)
die(sprintf("SQLSTATE %s, Driver info: %s/%s", $info[0], $info[1],
$info[2]));
else
die(sprintf("SQLSTATE %s", $info[0]));
Note that this bug is somewhat related to the question raised in
http://bugs.php.net/bug.php?id=44153 .
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
string(0) ""
array(1) {
[0]=>
string(0) ""
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
$pdo->getAttribute(-1); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); $pdo->getAttribute(-1);
var_dump($pdo->errorCode()); var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
Expected result:
Always return an array with three elements. Make checking the
errorInfo() easier.
Actual result:
--
See above. Array with only one element.
--
Edit this bug report at http://bugs.php.net/?id=44154&edit=1
#44153 [Opn]: PDO->errorCode() returns '' instead of SQLSTATE if no operation has been run
ID: 44153
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
New Comment:
The patch below allows you to do:
$error = $pdo->errorCode();
if (is_null($error)) {
// There's an empty error...
}
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44153.patch
More I look at it and more I think we should have a generic message
like "UNUSED" or something similar but I think NULL is also quite
straightforward.
Previous Comments:
[2008-10-24 23:34:18] [EMAIL PROTECTED]
What about returning NULL ? You could easily check the results using
is_null() and if it's null that means there's no errorCode().
Whereas when there's an error code you'll get the usual sqlstate
message/code.
What do you think? I think NULL would make great sense.
[2008-02-18 18:07:53] uwendel at mysql dot com
Description:
The PHP manual states that PDO->errorCode() returns the SQLSTATE
associated with the last operation run on the handle,
http://www.php.net/manual/en/function.PDO-errorCode.php
"Return Values
Returns a SQLSTATE, a five-character alphanumeric identifier defined in
the ANSI SQL-92 standard. Briefly, an SQLSTATE consists of a
two-character class value followed by a three-character subclass value.
A class value of 01 indicates a warning and is accompanied by a return
code of SQL_SUCCESS_WITH_INFO. Class values other than '01', except for
the class 'IM', indicate an error. The class 'IM' is specific to
warnings and errors that derive from the implementation of PDO (or
perhaps ODBC, if you're using the ODBC driver) itself. The subclass
value '000' in any class indicates that there is no subclass for that
SQLSTATE. "
What is PDO->errorCode() supposed to return if no operation has been
run on the handle yet?
If its valid to return any empty string, please add this to the
documentation.
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
var_dump($pdo->errorCode());'
string(0) ""
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());'
string(0) ""
Expected result:
Its a matter of taste. Personally I have a preference for returning
'0' as this makes checking the error code easier but this would be
sort of a BC break.
Actual result:
--
Empty string (see above).
--
Edit this bug report at http://bugs.php.net/?id=44153&edit=1
#44154 [Opn->Tbd]: PDO->errorInfo() does not always return three element array
ID: 44154
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
-Status: Open
+Status: To be documented
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Ok I have applied the patch to 5_3 and HEAD.
Previous Comments:
[2008-11-01 13:52:55] [EMAIL PROTECTED]
I have a very small patch that I could commit if someone else agrees.
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44154.patch
[2008-02-18 18:25:09] uwendel at mysql dot com
Description:
According to the manual one can expect PDO->errorInfo() to return an
array with three elements.
"Return Values
PDO->errorInfo() returns an array of error information about the last
operation performed by this database handle. The array consists of the
following fields:
Element Information
0 SQLSTATE error code (a five-character alphanumeric identifier
defined in the ANSI SQL standard).
1 Driver-specific error code.
2 Driver-specific error message."
http://www.php.net/manual/en/function.PDO-errorInfo.php
The manual is wrong. PDO will not always return an array with three
elements. There are two situations when you will get an array with only
one element.
1) driver has not set an error code yet
2) IM001 - not implemented (= driver can't set an error code)
I'd appreciate if you either document this or fix PDO->errorInfo() to
always return an array with three elements. My personal preference is
change PDO->errorInfo(). I don't see any reason why people would have to
use a complicated test like the following to avoid "undefined index"
style messages:
if (count($info = $pdo->errorInfo()) == 3)
die(sprintf("SQLSTATE %s, Driver info: %s/%s", $info[0], $info[1],
$info[2]));
else
die(sprintf("SQLSTATE %s", $info[0]));
Note that this bug is somewhat related to the question raised in
http://bugs.php.net/bug.php?id=44153 .
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
string(0) ""
array(1) {
[0]=>
string(0) ""
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
$pdo->getAttribute(-1); var_dump($pdo->errorCode());
var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); $pdo->getAttribute(-1);
var_dump($pdo->errorCode()); var_dump($pdo->errorInfo());'
Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support
this function: driver does not support that attribute in Command line
code on line 1
string(5) "IM001"
array(1) {
[0]=>
string(5) "IM001"
}
Expected result:
Always return an array with three elements. Make checking the
errorInfo() easier.
Actual result:
--
See above. Array with only one element.
--
Edit this bug report at http://bugs.php.net/?id=44154&edit=1
#44153 [Opn->Tbd]: PDO->errorCode() returns '' instead of SQLSTATE if no operation has been run
ID: 44153
Updated by: [EMAIL PROTECTED]
Reported By: uwendel at mysql dot com
-Status: Open
+Status: To be documented
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
-Assigned To:
+Assigned To: davidc
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-11-01 19:57:42] [EMAIL PROTECTED]
The patch below allows you to do:
$error = $pdo->errorCode();
if (is_null($error)) {
// There's an empty error...
}
http://dev.agoraproduction.com/php/5_3/ext/pdo/bug44153.patch
More I look at it and more I think we should have a generic message
like "UNUSED" or something similar but I think NULL is also quite
straightforward.
[2008-10-24 23:34:18] [EMAIL PROTECTED]
What about returning NULL ? You could easily check the results using
is_null() and if it's null that means there's no errorCode().
Whereas when there's an error code you'll get the usual sqlstate
message/code.
What do you think? I think NULL would make great sense.
[2008-02-18 18:07:53] uwendel at mysql dot com
Description:
The PHP manual states that PDO->errorCode() returns the SQLSTATE
associated with the last operation run on the handle,
http://www.php.net/manual/en/function.PDO-errorCode.php
"Return Values
Returns a SQLSTATE, a five-character alphanumeric identifier defined in
the ANSI SQL-92 standard. Briefly, an SQLSTATE consists of a
two-character class value followed by a three-character subclass value.
A class value of 01 indicates a warning and is accompanied by a return
code of SQL_SUCCESS_WITH_INFO. Class values other than '01', except for
the class 'IM', indicate an error. The class 'IM' is specific to
warnings and errors that derive from the implementation of PDO (or
perhaps ODBC, if you're using the ODBC driver) itself. The subclass
value '000' in any class indicates that there is no subclass for that
SQLSTATE. "
What is PDO->errorCode() supposed to return if no operation has been
run on the handle yet?
If its valid to return any empty string, please add this to the
documentation.
Reproduce code:
---
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("mysql:dbname=phptest;unix_socket=/tmp/mysql.sock", "root", "root");
var_dump($pdo->errorCode());'
string(0) ""
[EMAIL PROTECTED]:~/php53> sapi/cli/php -r '$pdo=new
PDO("sqlite:/tmp/foo.db"); var_dump($pdo->errorCode());'
string(0) ""
Expected result:
Its a matter of taste. Personally I have a preference for returning
'0' as this makes checking the error code easier but this would be
sort of a BC break.
Actual result:
--
Empty string (see above).
--
Edit this bug report at http://bugs.php.net/?id=44153&edit=1
#46615 [Asn->Csd]: SplHeap->key() returns count() instead of count() - 1
ID: 46615 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5.2CVS-2008-11-19 (CVS) Assigned To: davidc New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-11-19 13:34:11] [EMAIL PROTECTED] Description: Discussed here http://news.php.net/php.internals/41994. -- Edit this bug report at http://bugs.php.net/?id=46615&edit=1
#44151 [Opn]: Errors not cleaned properly
ID: 44151
Updated by: dav...@php.net
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
-Assigned To:
+Assigned To: davidc
New Comment:
Could you please test with the latest CVS or snapshot please? I have
made a few changes related to that lately and I'm wondering if that
could have fixed it.
Thanks,
Previous Comments:
[2008-02-18 16:51:11] uwendel at mysql dot com
Description:
According to the manual, PDO::errorInfo() returns the error information
about the "last operation performed by this database handle",
http://www.php.net/manual/en/function.PDO-errorInfo.php
What is PDO supposed to return if you perform two operations of which
the first fails and the second works fine, like this:
[1] THIS IS NO VALID SQL, I HOPE
[2] CREATE TABLE test(id int NOT NULL PRIMARY KEY, val VARCHAR(10), grp
VARCHAR(10))
Should errorInfo() return the error information from [1] or will the
error information be cleared prior to running [2]. In the latter case,
the user is given an additional easy way to check if an operation has
failed or not.
And the latter case (clear info before running [2]) is what I as the
desired behaviour.
Next question: which elements of the errorInfo() element shall be
reset? Currently it seems to me as if the SQLSTATE code is reset to
'0' but some drivers (e.g. PDO/MySQL, PDO/SQLlite, maybe more) do
not reset their driver specific fields. Haven't checked if that's an
issue caused by code from ext/pdo or from ext/pdo_mydriver.
Reproduce code:
---
--TEST--
PDO Common: PDO->errorInfo(), clear line after error
--SKIPIF--
--FILE--
exec('THIS IS NO VALID SQL, I HOPE');
var_dump($db->errorInfo());
var_dump($db->errorCode());
$db->exec('CREATE TABLE test(id int NOT NULL PRIMARY KEY, val
VARCHAR(10), grp VARCHAR(10))');
var_dump($db->errorInfo());
var_dump($db->errorCode());
print "done!";
?>
--EXPECTF--
array(3) {
[0]=>
string(5) "%s"
[1]=>
int(%d)
[2]=>
string(%d) "%s"
}
string(5) "%s"
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
string(5) "0"
done!
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=44151&edit=1
#46048 [Opn->Csd]: SimpleXML top-level @attributes not part of iterator (PHP_5_3 and above only!)
ID: 46048 Updated by: dav...@php.net Reported By: php at isnoop dot net -Status: Open +Status: Closed Bug Type: SimpleXML related Operating System: Ubuntu 8.04 server PHP Version: 5.3.0alpha3 Assigned To: davidc New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-01-29 22:45:54] php at isnoop dot net Bug confirmed still be present in 5.3.0beta1. [2009-01-16 20:16:08] php at zjs dot name I am experiencing the same problem on 5.3. The code used is the same used above. sheph...@ursa-minor:~/php5/sapi/cli$ ./php -v; ./php ~/code/scrap/php/bugs/46048.php PHP 5.3.0alpha4-dev (cli) (built: Jan 15 2009 17:22:45) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Array ( [key] => value ) [2008-12-09 01:51:33] php at isnoop dot net I have tested this with the two new PHP releases on yet another server: 5.3.0alpha3 Fails: [] [...@ianm:~/src/php-5.3.0alpha3/sapi/cli] ./php -v;./php ~/sandbox/bug46048.php PHP 5.3.0alpha3 (cli) (built: Dec 4 2008 17:18:52) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies Array ( [key] => value ) 5.2.8 Passes: [] [...@ianm:~/src/php-5.2.8/sapi/cli] ./php -v;./php ~/sandbox/bug46048.php PHP 5.2.8 (cli) (built: Dec 8 2008 17:34:28) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies Array ( [...@attributes] => Array ( [id] => 1 ) [key] => value ) [2008-11-17 21:27:47] php at isnoop dot net It appears that you're testing against 5.2.7 which I've verified doesn't exhibit this error. This problem only appears with the 5.3.0 releases. Both the 5.2.* releases and 5.3.* use libxml 2.6.31 on my primary test machine. It is possible that libxml is part of the problem, but it still stands that the problem does not manifest prior to 5.3. [2008-11-17 09:49:46] j...@php.net $ php t.php Array ( [...@attributes] => Array ( [id] => 1 ) [key] => value ) [j...@localhost ~]$ php -v PHP 5.2.7-dev (cli) (built: Oct 9 2008 16:54:00) (DEBUG) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies So still no bug. If you experience this even with proper XML, I guess it's your libxml that is a buggy version. (my PHP is build with libxml 2.7.2) 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/46048 -- Edit this bug report at http://bugs.php.net/?id=46048&edit=1
#46897 [Opn->Tbd]: ob_flush() should fail to flush unerasable buffers
ID: 46897
Updated by: dav...@php.net
Reported By: robin_fernandes at uk dot ibm dot com
-Status: Open
+Status: To be documented
Bug Type: Output Control
Operating System: *
PHP Version: 5.3CVS-2008-12-18 (snap)
Assigned To: davidc
New Comment:
New NOTICE issued:
Notice: ob_flush(): failed to flush buffer callback. in %s on line %d
Previous Comments:
[2008-12-18 14:15:20] j...@php.net
In HEAD there is improved output buffering code. Hence the difference.
And IMO, the proper fix for this is to simply backport the patch. (IIRC
that's already done, just wasn't allowed to be committed to 5.3 for some
stupid reason..)
[2008-12-18 12:27:16] robin_fernandes at uk dot ibm dot com
Description:
On 5_2 and 5_3, there is an inconsistency between ob_flush() and
ob_get_flush() when attempting to flush a buffer created with the flag
$erase=false:
- ob_get_flush() raises a notice and does NOT flush the buffer;
- ob_flush() DOES flush the buffer.
Note that on HEAD, both ob_get_flush() and ob_flush() raise a notice
and do NOT flush the buffer.
I think the behaviour in HEAD is correct. Here's a simple patch for 5_3
that resolves the inconsistency and makes it behave more like HEAD:
Index: output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.9
diff -u -w -p -r1.167.2.3.2.4.2.9 output.c
--- output.c18 Aug 2008 07:46:31 - 1.167.2.3.2.4.2.9
+++ output.c18 Dec 2008 11:30:01 -
@@ -774,6 +774,10 @@ PHP_FUNCTION(ob_flush)
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer. No buffer to flush.");
RETURN_FALSE;
}
+ if (OG(ob_nesting_level) && !OG(active_ob_buffer).status &&
!OG(active_ob_buffer).erase) {
+ php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE,
"failed to flush buffer %s", OG(active_ob_buffer).handler_name);
+ RETURN_FALSE;
+ }
php_end_ob_buffer(1, 1 TSRMLS_CC);
RETURN_TRUE;
More generally, the behaviour of output buffering functions when
dealing with unerasable buffers could benefit from better docs. I will
raise a separate doc bug with some suggestions.
Reproduce code:
---
Expected result:
[callback:1]Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
string(%d) "Attempt to flush unerasable buffer - should fail...
Notice: ob_flush(): failed to flush buffer callback in %s on line 11
bool(false)
"
Actual result:
--
[callback:1]Attempt to flush unerasable buffer - should fail...
[callback:2]bool(true)
string(11) "bool(true)
"
--
Edit this bug report at http://bugs.php.net/?id=46897&edit=1
#44409 [Opn]: PDO::FETCH_SERIALIZE calls __construct()
ID: 44409
Updated by: dav...@php.net
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: *
PHP Version: 5.3CVS-2008-03-11 (CVS)
New Comment:
Hmm is it supposed to say: PDO::FETCH_SERIZALIZE?
Previous Comments:
[2008-03-11 19:53:48] uwendel at mysql dot com
Description:
There seems to be very few documentation about PDO::FETCH_SERIALIZE in
the PHP manual but playing the guessing game from the code it seems that
this feature aims to support SPL/Serialize interface. As I'm not sure
about the purpose of PDO::FETCH_SERIALIZE I'm not sure if the following
is a bug or not. However, it seems to me that PDO::FETCH_SERIALIZE
unintentionally calls __construct().
One of the main ideas behind SPL/Serialize interface seems to be that
for unserialization the constructor of a class does not get called. The
constructor of a class has a different meaning than a helper function
like unserialize() and thus should not be called automatically. Let's
check:
class myclass implements Serialize {
public function __construct() {
printf("%s()\n", __METHOD__);
}
public function serialize() {
printf("%s()\n", __METHOD__);
return "any data from serialize()";
}
public function unserialize($dat) {
printf("%s(%s)\n", __METHOD__, var_export($dat, true));
}
}
$obj1 = new myclass()
---> myclass::__construct()
$tmp = serialize($obj1)
$obj2 = unserialize($tmp)
---> myclass::unserialize('any data from serizalize()')
__construct() gets called only once for object creation but not again
during unserialization. Let's try that with PDO:
[...]
$stmt = $db->query("SELECT dat FROM test");
$rows = $stmt->fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIZALIZE,
"myclass");
--> myclass::unserialize("data from DB")
--> myclass::__construct()
[...]
PDO first calls unserialize() as its supposed to do. But then it also
calls __construct() which is against the idea of the Serialize interface
not to call the constructor automatically during unserialization.
Reproduce code:
---
sapi/cli/php -r '$db = new PDO("sqlite:/tmp/foo"); $db->exec("DROP
TABLE test"); $db->exec("CREATE TABLE test(dat VARCHAR(100))");
$db->exec("INSERT INTO test(dat) VALUES (\"Data from DB\")"); class
myclass implements Serializable { public function __construct() {
printf("%s()\n", __METHOD__); } public function serialize() { return
"any data from serizalize()"; } public function unserialize($dat) {
printf("%s(%s)\n", __METHOD__, var_export($dat, true)); }} $stmt =
$db->query("SELECT * FROM test");
var_dump($stmt->fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIALIZE,
"myclass")); $obj = new myclass();
var_dump(unserialize(serialize($obj)));'
myclass::unserialize('Data from DB')
myclass::__construct()
array(1) {
[0]=>
object(myclass)#3 (0) {
}
}
myclass::__construct()
myclass::unserialize('any data from serizalize()')
object(myclass)#4 (0) {
}
--
Edit this bug report at http://bugs.php.net/?id=44409&edit=1
#44151 [Asn->NoF]: Errors not cleaned properly
ID: 44151
Updated by: dav...@php.net
Reported By: uwendel at mysql dot com
-Status: Assigned
+Status: No Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: davidc
Previous Comments:
[2008-12-17 18:05:38] dav...@php.net
Could you please test with the latest CVS or snapshot please? I have
made a few changes related to that lately and I'm wondering if that
could have fixed it.
Thanks,
[2008-02-18 16:51:11] uwendel at mysql dot com
Description:
According to the manual, PDO::errorInfo() returns the error information
about the "last operation performed by this database handle",
http://www.php.net/manual/en/function.PDO-errorInfo.php
What is PDO supposed to return if you perform two operations of which
the first fails and the second works fine, like this:
[1] THIS IS NO VALID SQL, I HOPE
[2] CREATE TABLE test(id int NOT NULL PRIMARY KEY, val VARCHAR(10), grp
VARCHAR(10))
Should errorInfo() return the error information from [1] or will the
error information be cleared prior to running [2]. In the latter case,
the user is given an additional easy way to check if an operation has
failed or not.
And the latter case (clear info before running [2]) is what I as the
desired behaviour.
Next question: which elements of the errorInfo() element shall be
reset? Currently it seems to me as if the SQLSTATE code is reset to
'0' but some drivers (e.g. PDO/MySQL, PDO/SQLlite, maybe more) do
not reset their driver specific fields. Haven't checked if that's an
issue caused by code from ext/pdo or from ext/pdo_mydriver.
Reproduce code:
---
--TEST--
PDO Common: PDO->errorInfo(), clear line after error
--SKIPIF--
--FILE--
exec('THIS IS NO VALID SQL, I HOPE');
var_dump($db->errorInfo());
var_dump($db->errorCode());
$db->exec('CREATE TABLE test(id int NOT NULL PRIMARY KEY, val
VARCHAR(10), grp VARCHAR(10))');
var_dump($db->errorInfo());
var_dump($db->errorCode());
print "done!";
?>
--EXPECTF--
array(3) {
[0]=>
string(5) "%s"
[1]=>
int(%d)
[2]=>
string(%d) "%s"
}
string(5) "%s"
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
string(5) "0"
done!
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=44151&edit=1
#44811 [Opn]: [Patch] Improve error message when creating new SoapClient with invalid data
ID: 44811
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: SOAP related
Operating System: Any
PHP Version: 5.3CVS-2008-04-23 (CVS)
Assigned To: davidc
New Comment:
Actually one thing you could do is simply this:
try {
new SoapClient("http://slashdot.org";);
} catch(Exception $e) {
var_dump(libxml_get_last_error());
}
If you store this into a variable, you'll be able to retrieve the
->message property which has the detailed message.
We are still evaluating the need of adding the detailed message
natively.
Previous Comments:
[2008-04-23 19:23:19] [EMAIL PROTECTED]
Description:
In case a new SoapClient is created and the loaded XML has problems,
the exact libxml2 error message is hidden.
It should be noted that with the provided patch, an extra \n gets
introduces which is from the libxml error context "message" member.
However I favor more exact error messages over formatting.
Index: php_sdl.c
===
RCS file: /repository/php-src/ext/soap/php_sdl.c,v
retrieving revision 1.88.2.12.2.9.2.2
diff -u -r1.88.2.12.2.9.2.2 php_sdl.c
--- php_sdl.c 31 Dec 2007 07:17:13 - 1.88.2.12.2.9.2.2
+++ php_sdl.c 23 Apr 2008 19:10:01 -
@@ -240,7 +240,12 @@
wsdl = soap_xmlParseFile(struri TSRMLS_CC);
if (!wsdl) {
- soap_error1(E_ERROR, "Parsing WSDL: Couldn't load from '%s'",
struri);
+ xmlErrorPtr xmlErrorPtr = xmlGetLastError();
+ if (xmlErrorPtr) {
+ soap_error2(E_ERROR, "Parsing WSDL: Couldn't load from
'%s': %s",
struri, xmlErrorPtr->message);
+ } else {
+ soap_error1(E_ERROR, "Parsing WSDL: Couldn't load from
'%s'",
struri);
+ }
}
zend_hash_add(&ctx->docs, struri, strlen(struri)+1, (void**)&wsdl,
sizeof(xmlDocPtr), NULL);
Reproduce code:
---
php -r 'new SoapClient("http://slashdot.org";);'
Expected result:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://slashdot.org': Premature end of data in
tag html line 3
in Command line code:1
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://slashdot.org' in Command line code:1
--
Edit this bug report at http://bugs.php.net/?id=44811&edit=1
#44929 [Bgs->Opn]: natsort and natcasesort fail if numbers in strings prepended by 0
ID: 44929 Updated by: [EMAIL PROTECTED] Reported By: kae at verens dot com -Status: Bogus +Status: Open Bug Type: Arrays related Operating System: Linux PHP Version: 5.2.6 Previous Comments: [2008-05-07 15:38:51] kae at verens dot com I'm sorry - I think I misunderstand something here. I have just tried with the example values in http://sourcefrog.net/projects/natsort/example-out.txt Expected result: no change from the input array to the outputted array. Actual result: the input array order is incorrect where values have a '0' in front of them Sample code: string '1-02' (length=4) 0 => string '1-2' (length=3) 2 => string '1-20' (length=4) 3 => string '10-20' (length=5) 4 => string 'fred' (length=4) 5 => string 'jane' (length=4) 6 => string 'pic01' (length=5) 8 => string 'pic02' (length=5) 9 => string 'pic02a' (length=6) 23 => string 'pic02000' (length=8) 14 => string 'pic05' (length=5) 7 => string 'pic2' (length=4) 10 => string 'pic3' (length=4) 11 => string 'pic4' (length=4) 12 => string 'pic 4 else' (length=10) 13 => string 'pic 5' (length=5) 15 => string 'pic 5 ' (length=6) 16 => string 'pic 5 something' (length=15) 17 => string 'pic 6' (length=5) 18 => string 'pic 7' (length=7) 19 => string 'pic100' (length=6) 20 => string 'pic100a' (length=7) 21 => string 'pic120' (length=6) 22 => string 'pic121' (length=6) 24 => string 'tom' (length=3) 25 => string 'x2-g8' (length=5) 27 => string 'x2-y08' (length=6) 26 => string 'x2-y7' (length=5) 28 => string 'x8-y8' (length=5) [2008-05-07 15:14:44] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php See also: http://sourcefrog.net/projects/natsort/ [2008-05-06 14:32:32] kae at verens dot com Description: natsort, which sorts arrays using natural language, does not understand numbers which begin with '0'. Reproduce code: --- string 'test01' (length=6) 2 => string 'test02' (length=6) 0 => string 'test012' (length=7) Actual result: -- array 1 => string 'test01' (length=6) 0 => string 'test012' (length=7) 2 => string 'test02' (length=6) -- Edit this bug report at http://bugs.php.net/?id=44929&edit=1
#44811 [Opn->Csd]: [Patch] Improve error message when creating new SoapClient with invalid data
ID: 44811
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: SOAP related
Operating System: Any
PHP Version: 5.3CVS-2008-04-23 (CVS)
Assigned To: davidc
Previous Comments:
[2008-05-07 14:19:30] [EMAIL PROTECTED]
Actually one thing you could do is simply this:
try {
new SoapClient("http://slashdot.org";);
} catch(Exception $e) {
var_dump(libxml_get_last_error());
}
If you store this into a variable, you'll be able to retrieve the
->message property which has the detailed message.
We are still evaluating the need of adding the detailed message
natively.
[2008-04-23 19:23:19] [EMAIL PROTECTED]
Description:
In case a new SoapClient is created and the loaded XML has problems,
the exact libxml2 error message is hidden.
It should be noted that with the provided patch, an extra \n gets
introduces which is from the libxml error context "message" member.
However I favor more exact error messages over formatting.
Index: php_sdl.c
===
RCS file: /repository/php-src/ext/soap/php_sdl.c,v
retrieving revision 1.88.2.12.2.9.2.2
diff -u -r1.88.2.12.2.9.2.2 php_sdl.c
--- php_sdl.c 31 Dec 2007 07:17:13 - 1.88.2.12.2.9.2.2
+++ php_sdl.c 23 Apr 2008 19:10:01 -
@@ -240,7 +240,12 @@
wsdl = soap_xmlParseFile(struri TSRMLS_CC);
if (!wsdl) {
- soap_error1(E_ERROR, "Parsing WSDL: Couldn't load from '%s'",
struri);
+ xmlErrorPtr xmlErrorPtr = xmlGetLastError();
+ if (xmlErrorPtr) {
+ soap_error2(E_ERROR, "Parsing WSDL: Couldn't load from
'%s': %s",
struri, xmlErrorPtr->message);
+ } else {
+ soap_error1(E_ERROR, "Parsing WSDL: Couldn't load from
'%s'",
struri);
+ }
}
zend_hash_add(&ctx->docs, struri, strlen(struri)+1, (void**)&wsdl,
sizeof(xmlDocPtr), NULL);
Reproduce code:
---
php -r 'new SoapClient("http://slashdot.org";);'
Expected result:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://slashdot.org': Premature end of data in
tag html line 3
in Command line code:1
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://slashdot.org' in Command line code:1
--
Edit this bug report at http://bugs.php.net/?id=44811&edit=1
Req #51939 [Opn->Asn]: Add xml_set_entity_decl_handler function
Edit report at https://bugs.php.net/bug.php?id=51939&edit=1
ID: 51939
Updated by: dav...@php.net
Reported by:mchenryc at gmail dot com
Summary:Add xml_set_entity_decl_handler function
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:XML related
PHP Version:trunk-SVN-2010-05-28 (SVN)
-Assigned To:
+Assigned To:davidc
Block user comment: N
Private report: N
Previous Comments:
[2010-05-28 01:40:45] mchenryc at gmail dot com
Description:
When parsing XML, PHP has no way to set a handler for general entities, though
a
handler can be set for unparsed entities.
Expat has deprecated the XML_SetUnparsedEntityDeclHandler in favor of
XML_SetEntityDeclHandler, which is called for all entity types (including
general
and unparsed).
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/expat.h?
revision=1.80&view=markup#l_311
PHP should add the xml_set_entity_decl_handler function to allow handling of
all
entity declarations.
Test script:
---
$data = ']>&generalEntity;';
function
h_entity_decl($parser,$entity_name,$is_parameter_entity,$value,$base,$system_id,$public_id,$notation_name)
{
echo "$entity_name - $is_parameter_entity - $value";
};
$parser = xml_parser_create();
xml_set_entity_decl_handler($parser, 'h_entity_decl');
xml_parse($parser,$data,false) or
die (sprintf("XML Error: %s at line %d\n",
xml_error_string(xml_get_error_code($parser)),
xml_get_current_line_number($parser)));
xml_parser_free($parser);
Expected result:
It should run with the following output:
generalEntity - 0 - General Entity
Actual result:
--
Fatal Error: Call to undefined function xml_set_entity_decl_handler()
--
Edit this bug report at https://bugs.php.net/bug.php?id=51939&edit=1
Req #51939 [Asn]: Add xml_set_entity_decl_handler function
Edit report at https://bugs.php.net/bug.php?id=51939&edit=1
ID: 51939
Updated by: dav...@php.net
Reported by:mchenryc at gmail dot com
Summary:Add xml_set_entity_decl_handler function
Status: Assigned
Type: Feature/Change Request
Package:XML related
PHP Version:trunk-SVN-2010-05-28 (SVN)
Assigned To:davidc
Block user comment: N
Private report: N
New Comment:
I've added a patch for this but I'd like to write a few more tests before
committing it. If you could apply it and let me know if this helps you that'd
be
nice.
Previous Comments:
[2011-07-19 12:21:20] dav...@php.net
The following patch has been added/updated:
Patch Name: bug51939.patch
Revision: 1311092480
URL:
https://bugs.php.net/patch-display.php?bug=51939&patch=bug51939.patch&revision=1311092480
[2010-05-28 01:40:45] mchenryc at gmail dot com
Description:
When parsing XML, PHP has no way to set a handler for general entities, though
a
handler can be set for unparsed entities.
Expat has deprecated the XML_SetUnparsedEntityDeclHandler in favor of
XML_SetEntityDeclHandler, which is called for all entity types (including
general
and unparsed).
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/expat.h?
revision=1.80&view=markup#l_311
PHP should add the xml_set_entity_decl_handler function to allow handling of
all
entity declarations.
Test script:
---
$data = ']>&generalEntity;';
function
h_entity_decl($parser,$entity_name,$is_parameter_entity,$value,$base,$system_id,$public_id,$notation_name)
{
echo "$entity_name - $is_parameter_entity - $value";
};
$parser = xml_parser_create();
xml_set_entity_decl_handler($parser, 'h_entity_decl');
xml_parse($parser,$data,false) or
die (sprintf("XML Error: %s at line %d\n",
xml_error_string(xml_get_error_code($parser)),
xml_get_current_line_number($parser)));
xml_parser_free($parser);
Expected result:
It should run with the following output:
generalEntity - 0 - General Entity
Actual result:
--
Fatal Error: Call to undefined function xml_set_entity_decl_handler()
--
Edit this bug report at https://bugs.php.net/bug.php?id=51939&edit=1
#26698 [NEW]: Thrown exceptions while evaluting argument to pass as parameter crash PHP
From: davidc at bLesys dot com
Operating system: Win XP Professional
PHP version: 5CVS-2003-12-22 (dev)
PHP Bug Type: Reproducible crash
Bug description: Thrown exceptions while evaluting argument to pass as parameter
crash PHP
Description:
(bug was not fixed in beta3 also)
While evaluting argument 3 to pass to method setProperties, an exception
is thrown but any attempt to rethrow this exception/new exception or
return from the method crashes PHP.
Strangely, no problem is encountered if this exception is thrown while
evaluting the first two arguments.
The solution for now is to create a local variable that holds the contents
of the argument. Then, we simply pass the local variable to the method,
but this creates additional work for the programmer.
Reproduce code:
---
setProperties($a,$b,$res->getFirst());
}
catch(Exception $e)
{
throw new Exception("Failed to get it!");
}
}
}
$p =( new Proxy());
$p->setObject($this,$o,$ret);?>
Expected result:
Thrown exception caught by PHP5's default handler (stack output, etc)
Actual result:
--
Apache2 dies
--
Edit bug report at http://bugs.php.net/?id=26698&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26698&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26698&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26698&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26698&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26698&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26698&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26698&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26698&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26698&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26698&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26698&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26698&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26698&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26698&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26698&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26698&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26698&r=float
#26697 [Com]: calling class_exists on a nonexistent class in __autoload results in segfault
ID: 26697
Comment by: davidc at blesys dot com
Reported By: arjen at glas dot its dot tudelft dot nl
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2003-12-22 (dev)
New Comment:
What happens, I think, is that __autoload starts recursing endlessly.
Do this:
$autotracker=false;
function __autoload ($n) {
global $autotracker; $n=strtolower($n);
if ($autotracker==$n)die("Attempting to autoload $n again");
$autotracker=$n;
//rest of function __autoload
}//end __autoload
Probably a bug, but rather easy to fix by the client programmer. I
think the bug I found today w/ thrown exceptions is much more dangerous
(http://bugs.php.net/bug.php?id=26698) because you can't really fix it
for all cases.
Previous Comments:
[2003-12-22 16:03:57] arjen at glas dot its dot tudelft dot nl
Description:
When calling class_exists on a nonexistent classname in __autoload,
you'll get a segfault.
This is in beta1, beta2 and beta3 (and now I had the time to create a
testcase and do a report). Which ran under apache2 (2.0.48) on gentoo
linux.
And then I saw this report:
http://bugs.php.net/bug.php?id=26630&edit=2
So I downloaded the php5-20031030 snapshot and there it also
segfaults...
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=26697&edit=1
#26789 [NEW]: NullPointerException desired
From: davidc at blesys dot com Operating system: (doesn't apply) PHP version: 5.0.0b3 (beta3) PHP Bug Type: Feature/Change Request Bug description: NullPointerException desired Description: I desire a NullPointerException to be thrown, like in Java. Currently, a fatal error triggers, stopping my entire application. Many times an object may be null, but the application can continue. In addition, if an exception were thrown, I could trace it to see why the exception occured. Reproduce code: --- $j=null; $j->someMethod(); Expected result: Fatal error: Call to a member function someMethod() on a non-object in file.php on line 2 -- Edit bug report at http://bugs.php.net/?id=26789&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26789&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26789&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26789&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26789&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26789&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26789&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26789&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26789&r=support Expected behavior: http://bugs.php.net/fix.php?id=26789&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26789&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26789&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26789&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26789&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26789&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26789&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26789&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26789&r=float
#26794 [Com]: $that not available in parent class
ID: 26794
Comment by: davidc at blesys dot com
Reported By: alex_boyer at hotmail dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-01-11
New Comment:
Sorry, I don't understand. Is $that a new feature of PHP5?
Previous Comments:
[2004-01-05 09:20:05] alex_boyer at hotmail dot com
i mean that $that is not available in parent class A (but IT IS
available in class B)
[2004-01-05 09:17:14] alex_boyer at hotmail dot com
Description:
$that is not available in parent class B (uncomment code in class A you
will see it). So it is not possible to clone class in a recursive
way.
Reproduce code:
---
class A {
public $a;
function __clone(){
//if( $that === null ) die('$that is null');
$this->a = $that->a;
}
}
class B extends A {
public $b;
function __clone(){
parent::__clone();
$this->b = $that->b;
}
}
$b = new B();
$b->a = 'AAA';
$b->b = 'BBB';
$clone = $b->__clone();
print_r($clone);
Expected result:
B Object
(
[b] => BBB
[a] => AAA
)
Actual result:
--
B Object
(
[b] => BBB
[a] =>
)
--
Edit this bug report at http://bugs.php.net/?id=26794&edit=1
#26794 [Com]: $that not available in parent class
ID: 26794
Comment by: davidc at blesys dot com
Reported By: alex_boyer at hotmail dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-01-11
New Comment:
Ah, I see. $that is the old one.
I have an ugly solution:a = $that->a;
}
}
class B extends A {
public $b;
function __clone($thatj=''){
if ( $thatj != '' )$that=$thatj;
parent::__clone($that);
$this->b = $that->b;
}
}
$b = new B();
$b->a = 'AAA';
$b->b = 'BBB';
$clone = $b->__clone();
print_r($clone);
?>
Previous Comments:
--------
[2004-01-11 22:34:21] davidc at blesys dot com
Sorry, I don't understand. Is $that a new feature of PHP5?
[2004-01-05 09:20:05] alex_boyer at hotmail dot com
i mean that $that is not available in parent class A (but IT IS
available in class B)
[2004-01-05 09:17:14] alex_boyer at hotmail dot com
Description:
$that is not available in parent class B (uncomment code in class A you
will see it). So it is not possible to clone class in a recursive
way.
Reproduce code:
---
class A {
public $a;
function __clone(){
//if( $that === null ) die('$that is null');
$this->a = $that->a;
}
}
class B extends A {
public $b;
function __clone(){
parent::__clone();
$this->b = $that->b;
}
}
$b = new B();
$b->a = 'AAA';
$b->b = 'BBB';
$clone = $b->__clone();
print_r($clone);
Expected result:
B Object
(
[b] => BBB
[a] => AAA
)
Actual result:
--
B Object
(
[b] => BBB
[a] =>
)
--
Edit this bug report at http://bugs.php.net/?id=26794&edit=1
#32400 [NEW]: MSSQL Error ignoring
From: davidc at densi dot com Operating system: Debian Testing PHP version: 4.3.10 PHP Bug Type: MSSQL related Bug description: MSSQL Error ignoring Description: This is a simple bug that I can fix in the mssql query but I believe that this should be ignored automaticly by PHP. Basicly, I run this specific sql query and it outputs an Unknown Error. Then I go to query analyzer and the query works. But there's null values warnings. I can't use any @ to ignore the error, it doesn't *ignore* it. I can run any other queries in my php scripts and they work fine. Reproduce code: --- http://undernetlinuxnewbie.org/pastebin/view.php?id=126 which works but I get this: Warning: Null value is eliminated by an aggregate or other SET operation. Expected result: SalesNAMELineDate Incoming Outgoing Area 12 David Mar 21, 2005 16 13 QC 04 Rob Mar 21, 2004 12 28 ON Actual result: -- PHP: Query error! Error message: DB Error: unknown error MSSQL: Query Outputs the good result. but this in the warnings: Warning: Null value is eliminated by an aggregate or other SET operation. -- Edit bug report at http://bugs.php.net/?id=32400&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32400&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32400&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32400&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32400&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32400&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32400&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32400&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32400&r=support Expected behavior: http://bugs.php.net/fix.php?id=32400&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32400&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32400&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32400&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32400&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32400&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32400&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32400&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32400&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32400&r=mysqlcfg
#32400 [Fbk->Opn]: MSSQL Error ignoring
ID: 32400 User updated by: davidc at densi dot com Reported By: davidc at densi dot com -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Debian Testing PHP Version: 4.3.10 New Comment: We are not compiling anything from the sources, we are using apt-get and debian packages, also, it's the newest packages(Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-9). I might just make a patch and submit it if there's nothing about that yet. Let me know. Thanks Previous Comments: [2005-03-21 22:37:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-03-21 21:01:06] davidc at densi dot com Description: This is a simple bug that I can fix in the mssql query but I believe that this should be ignored automaticly by PHP. Basicly, I run this specific sql query and it outputs an Unknown Error. Then I go to query analyzer and the query works. But there's null values warnings. I can't use any @ to ignore the error, it doesn't *ignore* it. I can run any other queries in my php scripts and they work fine. Reproduce code: --- http://undernetlinuxnewbie.org/pastebin/view.php?id=126 which works but I get this: Warning: Null value is eliminated by an aggregate or other SET operation. Expected result: SalesNAMELineDate Incoming Outgoing Area 12 David Mar 21, 2005 16 13 QC 04 Rob Mar 21, 2004 12 28 ON Actual result: -- PHP: Query error! Error message: DB Error: unknown error MSSQL: Query Outputs the good result. but this in the warnings: Warning: Null value is eliminated by an aggregate or other SET operation. -- Edit this bug report at http://bugs.php.net/?id=32400&edit=1
