Bug #52412 [Opn->Bgs]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412&edit=1
ID: 52412
Updated by: der...@php.net
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
-Status: Open
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
-Operating System: Windows
+Operating System: *
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
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
FWIW, this is "expected". The __autoload() method is the last line of
defense for PHP to find a class definition. If it can't find it, PHP
bails out with a fatal error. If you throw an exception, you basically
abort this final chance, and thus gives PHP you that fatal "can not find
class" error. However, you can catch the exception in the __autoload()
method,
Previous Comments:
[2011-02-16 08:05:14] michael at squiloople dot com
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e->getMessage();
}
// Outputs the exception as expected.
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid "method not found" error.
getMessage(), "\n";
}
[2010-09-03 03:26:56] php dot net at phrozenbyte dot de
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
[2010-07-23 09:34:02] madboyka at yahoo dot com
Description:
I've tried to do the following:
1. Wrote and autoload method, that throws an exception.
3. Made a static call on a non-existing class within a try block.
Tried this on windows 7 / Apache 2.2 / PHP 5.3.3.
Test script:
---
http://bugs.php.net/bug.php?id=52412&edit=1
Req #34906 [Asn]: mysql: no way to get errno for a failed secondary connection attempt
Edit report at http://bugs.php.net/bug.php?id=34906&edit=1
ID: 34906
Updated by: tony2...@php.net
Reported by:feldgendler at mail dot ru
Summary:mysql: no way to get errno for a failed secondary
connection attempt
Status: Assigned
Type: Feature/Change Request
Package:MySQL related
Operating System: *
PHP Version:5CVS-2005-10-19 (cvs)
-Assigned To:georg
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Reassigned to Johannes.
The patch is still available here:
http://dev.daylessday.org/diff/bug34906.diff
Previous Comments:
[2005-10-18 13:51:40] feldgendler at mail dot ru
About the patch: I think it's not enough. Once a connection attempt has
failed, conect_errno will be nonzero, and mysql_errno() without
arguments always will return this value. This will be too much deviation
from the current behavior -- in fact, many always call mysql_errno()
without arguments. Here is a typical script which will be broken:
if (!mysql_connect('dbhost', 'user', 'pass')) {
mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query("...")) {
echo mysql_errno(); // This will print connect_errno!
}
I think that connect_errno should be reset to zero somewhere, but I
don't know where it would be appropriate. mysql_errno() shouldn't reset
connect_errno because mysql_error() and mysql_errno() are expected to be
idempotent.
[2005-10-18 13:43:11] tony2...@php.net
Assigned to the maintainer.
Georg, please check the patch:
http://tony2001.phpclub.net/dev/tmp/bug34906.diff
[2005-10-18 13:19:52] feldgendler at mail dot ru
Description:
This is actually a bug in the well-defined and documented API, so there
is no reproduce code here.
After successfully establishing a connection, when an attempt to create
another connection fails, there is no way to find out the errno. This is
because mysql_errno() always uses an established link, either the one
passed as the argument or the default one. There is just no way to find
out why the second connection failed.
// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);
// at this point, $first_connection is the default link
// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);
// $second_connection is false,
// $first_connection is still the default link
echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection
Before stamping "Bogus" on this bug, please note the following:
1. I have read the manual about mysql_errno() and mysql_connect(). Every
word of it. Even more, I think that PHP currently behaves as documented.
But it's just wrong because there is no way to find out why a connection
has failed.
2. I have read other bug reports about mysql_errno(). They are actually
about other issues, or they don't state this problem clearly enough, so
I'm filing this bug report to make it clear what the problem is.
3. I have read the source code of the mysql extension. From the source,
I've found out that the error code and message from a failed connection
attempt is really stored in mysql_globals (connect_errno and
connect_error), but mysql_errno() PHP function only returns
MySG(connect_errno) when the function is invoked without arguments AND
there is no default link. If there is a default link, and an attempt to
establish a second one has failed, there isn't a way to have
MySG(connect_errno) returned to the PHP program.
It is not obvious how to fix this bug, because it isn't a deviation from
the documented behavior, but rather an incompleteness of the API. Two of
the possible approaches are proposed here:
http://www.mail-archive.com/internals@lists.php.net/msg02524.html
--
Edit this bug report at http://bugs.php.net/bug.php?id=34906&edit=1
Req #34906 [Asn]: mysql: no way to get errno for a failed secondary connection attempt
Edit report at http://bugs.php.net/bug.php?id=34906&edit=1
ID: 34906
Updated by: johan...@php.net
Reported by:feldgendler at mail dot ru
Summary:mysql: no way to get errno for a failed secondary
connection attempt
Status: Assigned
Type: Feature/Change Request
Package:MySQL related
Operating System: *
PHP Version:5CVS-2005-10-19 (cvs)
-Assigned To:johannes
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
The "easy" solution is to use mysqli without this default connection
magic.
Making this work doesn't look trivial as these two cases have to work:
mysql_connect('localhost', 'valid', 'password');
mysql_connect('localhost', 'invalid', 'something');
mysql_query('invalid query');
echo mysql_error(); // should report the query error
as well as
mysql_connect('localhost', 'valid', 'password');
mysql_query('invalid query');
mysql_connect('localhost', 'invalid', 'something');
echo mysql_error(); // Should report the connect error
Assigning to mysql team
Previous Comments:
[2011-02-16 11:43:05] tony2...@php.net
Reassigned to Johannes.
The patch is still available here:
http://dev.daylessday.org/diff/bug34906.diff
[2005-10-18 13:51:40] feldgendler at mail dot ru
About the patch: I think it's not enough. Once a connection attempt has
failed, conect_errno will be nonzero, and mysql_errno() without
arguments always will return this value. This will be too much deviation
from the current behavior -- in fact, many always call mysql_errno()
without arguments. Here is a typical script which will be broken:
if (!mysql_connect('dbhost', 'user', 'pass')) {
mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query("...")) {
echo mysql_errno(); // This will print connect_errno!
}
I think that connect_errno should be reset to zero somewhere, but I
don't know where it would be appropriate. mysql_errno() shouldn't reset
connect_errno because mysql_error() and mysql_errno() are expected to be
idempotent.
[2005-10-18 13:43:11] tony2...@php.net
Assigned to the maintainer.
Georg, please check the patch:
http://tony2001.phpclub.net/dev/tmp/bug34906.diff
[2005-10-18 13:19:52] feldgendler at mail dot ru
Description:
This is actually a bug in the well-defined and documented API, so there
is no reproduce code here.
After successfully establishing a connection, when an attempt to create
another connection fails, there is no way to find out the errno. This is
because mysql_errno() always uses an established link, either the one
passed as the argument or the default one. There is just no way to find
out why the second connection failed.
// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);
// at this point, $first_connection is the default link
// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);
// $second_connection is false,
// $first_connection is still the default link
echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection
Before stamping "Bogus" on this bug, please note the following:
1. I have read the manual about mysql_errno() and mysql_connect(). Every
word of it. Even more, I think that PHP currently behaves as documented.
But it's just wrong because there is no way to find out why a connection
has failed.
2. I have read other bug reports about mysql_errno(). They are actually
about other issues, or they don't state this problem clearly enough, so
I'm filing this bug report to make it clear what the problem is.
3. I have read the source code of the mysql extension. From the source,
I've found out that the error code and message from a failed connection
attempt is really stored in mysql_globals (connect_errno and
connect_error), but mysql_errno() PHP function only returns
MySG(connect_errno) when the function is invoked without arguments AND
there is no default link. If there is a default link, and an attempt to
establish a second one has failed, there isn't a way to have
MySG(connect_errno) returned to the PHP program.
It is not obvious how to fix this bug, because it isn't a deviation from
the documented behavior, but rather an incompleteness of the API. Two of
the possible approaches are proposed here:
http://www.mail-archive.com/internals@lists.php.net/msg02524.html
--
Edit this bug report at http://bugs.php.net/bug.php?id=34906&edit=1
Req #50892 [Com]: Protected members of non-congruent children classes are visible
Edit report at http://bugs.php.net/bug.php?id=50892&edit=1
ID: 50892
Comment by: normandiggs at gmail dot com
Reported by:EdwardDrapkin at gmail dot com
Summary:Protected members of non-congruent children classes
are visible
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
Another one example, even without "extends":
class Page_Element
{
protected $name = 'name*';
public function __construct(Page_Element $child = null)
{
echo $this->name;
echo $child->name;
}
}
new Page_Element(new Page_Element(null));
(from http://youtrack.jetbrains.net/issue/WI-4663)
So why $child->name can be accessed? It's new object!
Previous Comments:
[2010-05-06 21:58:21] php at b8r dot org
Our problem differs slightly from this issue, but I think they share a
root cause. Here's a sample of code with the expected outcome.
abstract class A {
/**
* undocumented function
*
* @return void
*/
public function __get($propertyName)
{
$val = $this->$propertyName;
echo "Current Value of '{$propertyName}' is '{$val}'\n";
return $val;
}
public function __set($propertyName, $propertyValue)
{
echo "Setting Property '{$propertyName}' to
'{$propertyValue}'\n";
$this->$propertyName = $propertyValue;
}
}
class B extends A {
protected $name;
public function populateName($val) {
$a = 'name';
$this->$a = $val;
}
public function testit() {
$b = new B();
$b->name = 'internal';
$b->name;
}
}
$two = new B();
$two->name = 'external';
$two->name;
$two->testit();
Expected Results:
-
Setting Property 'name' to 'external'
Current Value of 'name' is 'external'
Setting Property 'name' to 'internal'
Current Value of 'name' is 'internal'
Actual Results:
Setting Property 'name' to 'external'
Current Value of 'name' is 'external'
[2010-05-06 21:39:30] php at b8r dot org
It causes more problems then the original poster notes. We've run into
problems using __get and __set. Since php see's the member as "in scope"
for both classes, the __get and __set methods don't get called.
[2010-02-02 03:28:51] col...@php.net
At a second glance, it really looks like it is wrong.
The visibility check should also be based on the object from which the
properties are read.
As for my "it works that way in Java" argument, it contradicts the java
specifications:
http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.6.2.1
and hence is invalid. (Thanks oorza for pointing that out)
There is no design ground to accept that, it is a bug. The question that
remains is: is it worth to fix BC-wise?
[2010-02-01 14:23:51] johan...@php.net
That's a fundamental part of a class based inheritance system.Changing
this won't only affect BC but also the fundamental design.
[2010-02-01 14:15:28] col...@php.net
Even though it feels odd, it's how the checks are currently designed.
The same applies to i.e. Java. I guess we cannot change things here
without introducing nasty and hard to track BC breaks.
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/bug.php?id=50892
--
Edit this bug report at http://bugs.php.net/bug.php?id=50892&edit=1
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412&edit=1
ID: 52412
Comment by: madboyka at yahoo dot com
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
To: der...@php.net
I don't think you've read the documentation on autoloading yourself:
http://www.php.net/manual/en/language.oop5.autoload.php
The first note states that since PHP 5.3, you may throw an exception
from the autoload function (even if the class can be loaded) and catch
that exception without a problem. Examples #3 and #4 in the
documentation entry demonstrate this. This works when the autoload
function gets invoked when instantiating a class, but doesn't when you
make a static call on it. This behavior is not consistent.
Also, take a look at michael@...'s workaround, which unexpectedly works
great. And don't tell me that PHP behaves as "expected".
I understand, that this is not a major bug, we all can live without a
fix, but at least mark it as to be fixed in the far future.
Previous Comments:
[2011-02-16 11:24:38] der...@php.net
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
FWIW, this is "expected". The __autoload() method is the last line of
defense for PHP to find a class definition. If it can't find it, PHP
bails out with a fatal error. If you throw an exception, you basically
abort this final chance, and thus gives PHP you that fatal "can not find
class" error. However, you can catch the exception in the __autoload()
method,
[2011-02-16 08:05:14] michael at squiloople dot com
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e->getMessage();
}
// Outputs the exception as expected.
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid "method not found" error.
getMessage(), "\n";
}
[2010-09-03 03:26:56] php dot net at phrozenbyte dot de
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
[2010-07-23 09:34:02] madboyka at yahoo dot com
Description:
I've tried to do the following:
1. Wrote and autoload method, that throws an exception.
3. Made a static call on a non-existing class within a try block.
Tried this on windows 7 / Apache 2.2 / PHP 5.3.3.
Test script:
---
http://bugs.php.net/bug.php?id=52412&edit=1
Bug #53850 [Com]: openssl_pkey_export() with password not protecting private key
Edit report at http://bugs.php.net/bug.php?id=53850&edit=1
ID: 53850
Comment by: jason dot gerfen at gmail dot com
Reported by:jason dot gerfen at gmail dot com
Summary:openssl_pkey_export() with password not protecting
private key
Status: Open
Type: Bug
Package:OpenSSL related
Operating System: arch linux x86_64
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Can I get an update on this status?
Previous Comments:
[2011-01-31 15:18:56] jason dot gerfen at gmail dot com
Since I have not heard anything else about this I did some digging to
try and identify the problem.
I have been adding some warning output in the
'openssl-1.0.0c/crypto/pem/pem_pkey.c' file after reviewing the the
'php-5.3.5/ext/openssl/openssl.c' file and noticing and focusing on the
calls to the OpenSSL shared objects for 'PEM_write_bio_PrivateKey()'.
When adding the warning output flags in the
'OpenSSL-1.0.0c/crypt/pem/pem_pkey.c' the password argument would always
display as '(null)'.
Correct me if I am looking the wrong spot in helping identify the
problem.
[2011-01-28 19:42:32] jason dot gerfen at gmail dot com
I have verified this under the following conditions.
Arch Linux x86_64 installation
This configuration returns a password protected private key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-0.9.8q
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-0.9.8q]
This configuration however does not return a password protected key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-1.0.0c
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-1.0.0c]
Anything else you might find pertinent?
[2011-01-26 20:12:04] paj...@php.net
There is no different code in php to deal with this function.
If two versions of openssl give you two different results then it is a
openssl
problem, not php.
Also I would like you to test using the same PHP versions vs two
openssl, then we
can begin to discuss a possible issue. Be sure to use the latest
versions
available at php.net, not the centos (or any other distro) you use.
[2011-01-26 20:04:50] jason dot gerfen at gmail dot com
Description:
I have tested this against php5.3.5 with OpenSSL 1.0.0c (arch linux) vs
an older server running php5.2.14 with OpenSSL 0.9.8e (centos linux).
Test script:
---
$opts = array('config'=>'openssl.cnf',
'encrypt_key'=>true,
'private_key_type'=>OPENSSL_KEYTYPE_RSA,
'digest_alg'=>'sha256',
'private_key_bits'=>2048,
'x509_extensions'=>'usr_cert');
$handle = openssl_pkey_new($opts);
openssl_pkey_export($handle, $privatekey, sha1($_SERVER['REMOTE_ADDR']),
$opts);
echo $privatekey;
Expected result:
CentOS example output
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C93B386451093918
buV1Kuaiu8QXhSeBdAF9Le2u+SSzaEtrHw6rLq19xL+9lWuwf4dFtrMPRI/PPvA5
HwBB7ZzT1AAzOAK2AnDiND3+n6IyqrkQjD7R0bGY6VLXdMr3qgGiJOkmsroF5t/H
LQEFGn9F8eOfEQTjkz4h9KYF/traXZSayBjNQ37fL42HO4M5WY0Ehms6bfeU5BN5
1d+NdENKLK0KVIJDNM3clQoHCc2KJwq70CeZmKq+tIG7UdigxmW0f9B/BMSM8PFx
3cFzt1eZVj23jPO65icEfqLWvdYUpOqFfZc17Si87LW8ExvO8yu4UPrk8iRR8eFH
LeOCPobR446Ehq8XBgFiFp8kzus5vDbqRLbMaBqul/mVWDmkpcyrnWJVAfginUar
FDTji8Ge8Zv5GgpuS2tjYkQpykthA17SKxDGe8s26feaHkErEanTWg5o50RP1oUo
1e2rrX+PVFoukN9f+j5OiScC8QDVfBcSZZYvfRmkE1SnF3S3CAVdtDIcqmy33WY+
Icx/n2uh3Y4tYafzSu/5O8ZeBzGUz3eKWMIAL66mxOclPAceWsQ6Ry22IBdjr+7p
Af3IKo4sWVtj3mOlrwNdNX9JtdHYiskNTVJ7+7DBlmbM+lfQlvb7wBsVek9ex6k2
qxWv250S+rdWuXBx3WuleQsQ14gBtX7Rf0Sk3DvOTinaU9C5n8xwaO9GWS0CJtjA
AkDTLZ0rylVjfdd3W7fjxfYtQEwnbKeIC1SEKuNR8tv6GXGuubU5Nt8Q5TIhZIYL
p2H027lafTE1Ky+KIRD0qZWfSEAujrxJVnH1n62edYxzWXfr+onS0g==
-END RSA PRIVATE KEY-
Actual result:
--
Arch linux sample output
-BEGIN ENCRYPTED PRIVATE KEY-
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIkd4I9LadOsYCAggA
MBQGCCqGSIb3DQMHBAhqJEWqm0xA9ASCAoDgWeRhfyKrCqfW7aSW1rYs8LVjN3ug
p9Kn6U7YZydHwxYdwNSK80i0yw+yU+ovVck2BdCBnm8ggdyXgS5UVTt5bnJHIHls
rEe4spLl8hkc0sOcL/ZseVBoxKIan7ZY1c0AysAwmrniFXKehSTCByDMUC58rl6H
gejVJk4+yebHuLqeq7z9d9dIvEuAFI9qjZjqUhq8wsCdN2+scFi/3/DXDp1V5/AS
SCeIsVsvcBNPaI8CYP48R13+mQJ+AGAWewcoHtwu8IQGuG46vlqOaYULCfInr/w7
/Y+Ttd2Hd6RHcnE9vTW7bhOn49v6KCtcwpcAtSz2kHrAufGxjAMzFV2oEVZPsDGM
4Rf3H1JtlJKIFYktTLoz9/07kQR0c6S1UkBa2oG/O7G0
[PHP-BUG] Bug #54031 [NEW]: parse_url failing for certain partial URLs
From:
Operating system: Mac OS X 10.6.6
PHP version: 5.3.5
Package: URL related
Bug Type: Bug
Bug description:parse_url failing for certain partial URLs
Description:
The parse_url function fails to parse any partial URL with a colon followed
by a
slash ":/" in it. It should have no problems parsing them though, since
it's
easy to determine whether a URL is partial or not (any string that does not
start with a scheme [ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )] and then
an
authority [which in the case of URLs starts with two slashes "//"] cannot
be a
URL; see RFC 3986).
In the case of partial URLs, it would be expected that parse_url acts as if
"http://tld"; was prepended to the input string (without returning the
"scheme"
or "host" parts, obviously).
The reason I'm filing this as a bug is because a script which uses a
trusted
source of a partial URL (such as $_SERVER['REQUEST_URI'] in most
environments)
and relies on parse_url will fail as soon as the visitor adds ":/"
somewhere in
the path.
My current workaround is to check whether the URL is partial ($url{0} ==
'/' is
sufficient in most cases) and if so, prepend a scheme and authority to it
before
passing it to parse_url.
Test script:
---
$ php -r 'var_dump(parse_url("/?x=:/"));' # Fails
$ php -r 'var_dump(parse_url("/?x=:)"));' # Works
Expected result:
$ php -r 'var_dump(parse_url("/?x=:/"));'
array(2) {
["path"]=>
string(1) "/"
["query"]=>
string(4) "x=:/"
}
$ php -r 'var_dump(parse_url("/?x=:)"));'
array(2) {
["path"]=>
string(1) "/"
["query"]=>
string(4) "x=:)"
}
Actual result:
--
$ php -r 'var_dump(parse_url("/?x=:/"));'
bool(false)
$ php -r 'var_dump(parse_url("/?x=:)"));'
array(2) {
["path"]=>
string(1) "/"
["query"]=>
string(4) "x=:)"
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54031&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54031&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54031&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54031&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54031&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54031&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54031&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54031&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54031&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54031&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54031&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54031&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54031&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54031&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54031&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54031&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54031&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54031&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54031&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54031&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54031&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54031&r=mysqlcfg
Bug #50787 [Csd->ReO]: stream_set_write_buffer() has no effect on socket streams
Edit report at http://bugs.php.net/bug.php?id=50787&edit=1
ID: 50787
Updated by: cataphr...@php.net
Reported by:vnegrier at optilian dot com
Summary:stream_set_write_buffer() has no effect on socket
streams
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Streams related
Operating System: linux
PHP Version:5.3.1
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
I'm reopening this because the fix makes the meaning of
PHP_STREAM_OPTION_WRITE_BUFFER ambiguous.
For the plain wrapper it's used as a wrapper for setvbuf and the only
values it accepts are 0, 1 and 2, for _IOFBF, _IOLBF and _IONBF.
For the socket stream, it's being used as a synonymous of
PHP_STREAM_OPTION_SET_CHUNK_SIZE. This makes no sense, especially since
the chunk size is also used for read buffering.
I understand the problem, but this can't be the solution; I'm reverting
this patch since setvbuf is specific to the stdio, but not without a
solution first -- perhaps a new function to change the chunk size.
Previous Comments:
[2010-02-03 20:21:40] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=294453
Log: - Fixed bug #50787 (stream_set_write_buffer() has no effect on
socket streams).
[2010-01-18 12:50:15] il...@php.net
This bug has been fixed in SVN.
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.
[2010-01-18 12:50:09] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=293699
Log: Fixed bug #50787 (stream_set_write_buffer() has no effect on socket
streams).
[2010-01-17 19:03:31] vnegrier at optilian dot com
Description:
Socket streams do not implement the PHP_STREAM_OPTION_WRITE_BUFFER call,
and the stream chunk size is always fixed at 8192 bytes.
This is not a problem with SOCK_STREAM type sockets, but with SOCK_DGRAM
is breaks the datagrams if they are more than 8192 bytes (which is IMHO
a bug).
Here is a patch against 5.3.1 to add support for
stream_set_write_buffer() with socket streams:
--- main/streams/xp_socket.c.orig 2010-01-17 19:56:39.0
+0100
+++ main/streams/xp_socket.c2010-01-17 19:59:34.0 +0100
@@ -266,6 +266,7 @@
int oldmode, flags;
php_netstream_data_t *sock =
(php_netstream_data_t*)stream->abstract;
php_stream_xport_param *xparam;
+ size_t size;
switch(option) {
case PHP_STREAM_OPTION_CHECK_LIVENESS:
@@ -400,6 +401,14 @@
return
PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
+ case PHP_STREAM_OPTION_WRITE_BUFFER:
+ if (ptrparam)
+ size = *(size_t *)ptrparam;
+ else
+ size = PHP_SOCK_CHUNK_SIZE;
+ php_stream_set_chunk_size(stream, size);
+ return PHP_STREAM_OPTION_RETURN_OK;
+
default:
return PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=50787&edit=1
Bug #50787 [ReO]: stream_set_write_buffer() has no effect on socket streams
Edit report at http://bugs.php.net/bug.php?id=50787&edit=1
ID: 50787
Updated by: cataphr...@php.net
Reported by:vnegrier at optilian dot com
Summary:stream_set_write_buffer() has no effect on socket
streams
Status: Re-Opened
Type: Bug
Package:Streams related
Operating System: linux
PHP Version:5.3.1
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Just a few more comments:
Strangely, PHP_STREAM_OPTION_WRITE_BUFFER also controls the flag
PHP_STREAM_FLAG_NO_BUFFER, which is used only for reading (controls
whether to keep a PHP read buffer or not), which is also a target of
PHP_STREAM_OPTION_READ_BUFFER. So there's already some mixing of read
and write semantics in PHP_STREAM_OPTION_WRITE_BUFFER.
In any case, I still think this should be revisited.
Previous Comments:
[2011-02-16 18:33:46] cataphr...@php.net
I'm reopening this because the fix makes the meaning of
PHP_STREAM_OPTION_WRITE_BUFFER ambiguous.
For the plain wrapper it's used as a wrapper for setvbuf and the only
values it accepts are 0, 1 and 2, for _IOFBF, _IOLBF and _IONBF.
For the socket stream, it's being used as a synonymous of
PHP_STREAM_OPTION_SET_CHUNK_SIZE. This makes no sense, especially since
the chunk size is also used for read buffering.
I understand the problem, but this can't be the solution; I'm reverting
this patch since setvbuf is specific to the stdio, but not without a
solution first -- perhaps a new function to change the chunk size.
[2010-02-03 20:21:40] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=294453
Log: - Fixed bug #50787 (stream_set_write_buffer() has no effect on
socket streams).
[2010-01-18 12:50:15] il...@php.net
This bug has been fixed in SVN.
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.
[2010-01-18 12:50:09] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=293699
Log: Fixed bug #50787 (stream_set_write_buffer() has no effect on socket
streams).
[2010-01-17 19:03:31] vnegrier at optilian dot com
Description:
Socket streams do not implement the PHP_STREAM_OPTION_WRITE_BUFFER call,
and the stream chunk size is always fixed at 8192 bytes.
This is not a problem with SOCK_STREAM type sockets, but with SOCK_DGRAM
is breaks the datagrams if they are more than 8192 bytes (which is IMHO
a bug).
Here is a patch against 5.3.1 to add support for
stream_set_write_buffer() with socket streams:
--- main/streams/xp_socket.c.orig 2010-01-17 19:56:39.0
+0100
+++ main/streams/xp_socket.c2010-01-17 19:59:34.0 +0100
@@ -266,6 +266,7 @@
int oldmode, flags;
php_netstream_data_t *sock =
(php_netstream_data_t*)stream->abstract;
php_stream_xport_param *xparam;
+ size_t size;
switch(option) {
case PHP_STREAM_OPTION_CHECK_LIVENESS:
@@ -400,6 +401,14 @@
return
PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
+ case PHP_STREAM_OPTION_WRITE_BUFFER:
+ if (ptrparam)
+ size = *(size_t *)ptrparam;
+ else
+ size = PHP_SOCK_CHUNK_SIZE;
+ php_stream_set_chunk_size(stream, size);
+ return PHP_STREAM_OPTION_RETURN_OK;
+
default:
return PHP_STREAM_OPTION_RETURN_NOTIMPL;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=50787&edit=1
Bug #41806 [Com]: milliseconds in date function
Edit report at http://bugs.php.net/bug.php?id=41806&edit=1
ID: 41806
Comment by: somemail at gmail dot com
Reported by:lordi at msdi dot ca
Summary:milliseconds in date function
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: FreeBSD 6.2-RELEASE
PHP Version:5.2.3
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
The problem still exists (Debian, PHP 5.2.6-1), even though the example
wasn't good enough.
Reproduce code:
---
echo date('H:i:s.u', microtime(true));
echo microtime(true);
Expected:
---
20:15:44.38
1297880144.38
Actual:
---
20:15:44.00
1297880144.38
Previous Comments:
[2007-07-12 19:04:50] der...@php.net
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
This is correct, it states that the timestamp is an integer, and that it
defaults to the value of "time()" in the documentation. time() does not
return a float with fractions of a second:
http://no.php.net/date:
Returns a string formatted according to the given format string using
the given integer timestamp or the current time if no timestamp is
given. In other words, timestamp is optional and defaults to the value
of time().
[2007-06-26 00:27:39] sni...@php.net
I think someone forgot to commit the part to the ext/date/lib/ side of
things when adding 'u' format as I can't see anywhere where t->f would
be set to anything but 0..
[2007-06-25 23:53:12] lordi at msdi dot ca
Description:
Hi,
the "u" parameters in the date function should return milliseconds, but
it always returns zeros.
Reproduce code:
---
date_default_timezone_set('America/Montreal');
echo date ('H:i:s:u');
Expected result:
19:50:39:123456
Actual result:
--
19:50:39:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=41806&edit=1
[PHP-BUG] Req #54032 [NEW]: ability to to handle Class not found error
From: Operating system: PHP version: 5.3.5 Package: SPL related Bug Type: Feature/Change Request Bug description:ability to to handle Class not found error Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit bug report at http://bugs.php.net/bug.php?id=54032&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54032&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54032&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54032&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54032&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54032&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54032&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54032&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54032&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54032&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54032&r=support Expected behavior: http://bugs.php.net/fix.php?id=54032&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54032&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54032&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54032&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54032&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54032&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54032&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54032&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54032&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54032&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54032&r=mysqlcfg
Req #54032 [Com]: ability to to handle Class not found error
Edit report at http://bugs.php.net/bug.php?id=54032&edit=1 ID: 54032 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:ability to to handle Class not found error Status: Open Type: Feature/Change Request Package:SPL related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: *exists -> exit *exection -> execution * spl autoload callbacks was executed -> spl autoload callbacks was executed without finding the class * I cannot continue the normal execution flow -> I couldn't continue the normal execution flow * from a higher level -> at a higher level sorry, its getting late, and my english skill degrades with sleep deprivation Previous Comments: [2011-02-17 00:11:01] tyra3l at gmail dot com Description: currently you can throw an exception from the autoloader, hence if you can't find a class, your application can gracefully exists, instead of exiting via the class not found fatal error. my problem is, that I would like to use multiple autoloader (for example in a project which uses multiple component, or framework), but in this case, I can't throw an Exception from my autoloader, because maybe the other autoloaders could load the class. if I'm sure that I will register the last autoloader, the this isn't a problem(my last autoloader will throw the Exception on missing class), but maybe I have to load a component late of the exection. it would be cool, if I could somehow register a callback which will be called, when the spl autoload callbacks was executed, but the class couldn't be loaded of course, from this callback, I cannot continue the normal execution flow, however I can log the error, and let the callback return and get the class not found fatal error, or throw an Exception, and handle/log the error from a higher level. -- Edit this bug report at http://bugs.php.net/bug.php?id=54032&edit=1
[PHP-BUG] Req #54033 [NEW]: add get_error_handler and get_exception handler
From: Operating system: PHP version: 5.3.5 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:add get_error_handler and get_exception handler Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit bug report at http://bugs.php.net/bug.php?id=54033&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54033&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54033&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54033&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54033&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54033&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54033&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54033&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54033&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54033&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54033&r=support Expected behavior: http://bugs.php.net/fix.php?id=54033&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54033&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54033&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54033&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54033&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54033&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54033&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54033&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54033&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54033&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54033&r=mysqlcfg
Req #54033 [Opn->Bgs]: add get_error_handler and get_exception handler
Edit report at http://bugs.php.net/bug.php?id=54033&edit=1 ID: 54033 Updated by: ras...@php.net Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler -Status: Open +Status: Bogus Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: set_error_handler() already returns the previously set error handler, if any. Previous Comments: [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at http://bugs.php.net/bug.php?id=54033&edit=1
Req #54033 [Com]: add get_error_handler and get_exception handler
Edit report at http://bugs.php.net/bug.php?id=54033&edit=1 ID: 54033 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler Status: Bogus Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N New Comment: of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael Previous Comments: [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at http://bugs.php.net/bug.php?id=54033&edit=1
Req #53888 [Asn->Csd]: ftruncate() does not work with user-defined stream wrappers
Edit report at http://bugs.php.net/bug.php?id=53888&edit=1 ID: 53888 Updated by: cataphr...@php.net Reported by:ivan dot enderlin at hoa-project dot net Summary:ftruncate() does not work with user-defined stream wrappers -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Filesystem function related PHP Version:trunk-SVN-2011-01-31 (SVN) Assigned To:cataphract Block user comment: N Private report: N New Comment: Implemented for trunk. Previous Comments: [2011-02-17 01:25:35] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=308410 Log: - Classes that implement stream wrappers can define a method called stream_truncate that will respond to truncation, e.g. through ftruncate. Closes feature request #53888. [2011-02-01 17:52:25] ivan dot enderlin at hoa-project dot net Ok, it's not a bug, it's a missing feature. So, do you have any workaround to propose me :-p ? If I can participate to the patch, I'm in. [2011-02-01 13:57:08] cataphr...@php.net This is a feature request because it requires extending the user-land stream wrapper model. I can take care of it, but I'm more inclined to make it trunk only. [2011-02-01 10:25:59] ivan dot enderlin at hoa-project dot net The bug is open since 2006-07-06, I think that the bug owner is either dead either away :-). Maybe we can focus on this bug which has a detailed example and a detailed description. What do you think about it :-) ? [2011-02-01 08:49:22] paj...@php.net Let keep it open unless the other bug has clear tests cases and similar information, which is not the case now. 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/bug.php?id=53888 -- Edit this bug report at http://bugs.php.net/bug.php?id=53888&edit=1
Req #54033 [Bgs->ReO]: add get_error_handler and get_exception handler
Edit report at http://bugs.php.net/bug.php?id=54033&edit=1 ID: 54033 Updated by: ras...@php.net Reported by:tyra3l at gmail dot com Summary:add get_error_handler and get_exception handler -Status: Bogus +Status: Re-Opened Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.5 Block user comment: N Private report: N Previous Comments: [2011-02-17 01:04:00] tyra3l at gmail dot com of course it returns the callback. but: - you can't get it without overwriting - it doesn't return the error_types, hence you won't know on which error should you call the previous handler - if you would think, that maybe the restore_error_handler would come to the rescue(you set your error handler, in your error handler you catch everything, and restore the previous handler for the errors that isn't for you and and call the original error handler with trigger_error): you can only tigger E_USER_*. :( am I missing something? if not, please re-open the issue, because it isn't bogus. Tyrael [2011-02-17 00:50:53] ras...@php.net set_error_handler() already returns the previously set error handler, if any. [2011-02-17 00:44:58] tyra3l at gmail dot com Description: my co-worker had a problem with the Zend Framework Soap Server class: he was using trigger_error for handling the application level errors, and the ZF Soap Server class set his own error_handler, so my co-worker's error handler was swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you have an userspace error handler then every error type, which isn't observed will be discarded) I mentioned this on twitter (I wasn't really nice) http://twitter.com/#!/Tyr43l/status/22704699030 and Matthew Weier O'Phinney responded that they had to do this, because there was some quirks about the SoapServer or DomDocument class. so if they don't set their error_handler, they can't handle the error, if they do, they will overwrite any existing error_handler. if there would be a way, to get the current(previous) error handler, then they could have save the current/previous error handler (with the error type parameter!) and from their error handler, they could have call the applevel error handler callback. of course, some stackable mechanism, like the spl_autoload would be a more better approach but that would break BC, at least I couldn't figure out a way to do it without problems. I will ask Matthew to comment on this issue (what was the exact problem that forced them to set the error handler at the first place) -- Edit this bug report at http://bugs.php.net/bug.php?id=54033&edit=1
Req #43304 [Com]: Casting During Comparison
Edit report at http://bugs.php.net/bug.php?id=43304&edit=1
ID: 43304
Comment by: kissifrot at gmail dot com
Reported by:ken at smallboxsoftware dot net
Summary:Casting During Comparison
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: ALL
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
I agree with that, for example if I have
$ric1 = '11000198358';
$ric2 = '11000198455';
var_dump($ric1 == $ric2)
should return false, not true, just because it's logical.
But the current behavior makes PHP somewhat unreliable :(
Previous Comments:
[2008-09-06 23:49:58] drm at melp dot nl
Though documented (http://www.php.net/language.operators, quote "If you
compare two numerical strings, they are compared as integers."), this is
indeed unexpected behaviour (and thus a bug)
This bug will probably be closed and denoted as "sorry, documented
feature", but I think this is really a candidate for revision in any
next major PHP version.
Comparison should always feel intuitive, and PHP has made the move
towards more "secure" defaults. This falls (imo) under the same
category. Please witness following example.
client side code:
No selection
whatever
selection
(...)
server side code:
if ( $_GET['selection'] == 0 ) {
echo 'Please make a selection!';
} else {
// process request
}
Though the example does not imply any security issues, they are not
unimaginable. Please reconsider the behaviour of the comparison
operator.
My suggestion:
Implement (and document!) the following:
Any left side of the comparison is only cast to number if the right side
doesn't fail to. Casting to number is considered successful, if and only
if the string would syntactically be a number in the PHP
Therefore, the string should match the following:
http://php.net/language.types.integer
http://php.net/language.types.float
[At both pages, see the "formal" definition of both types.]
In any OTHER case, the comparison should act as follows:
If ANY of the sides is of a string type (and of course fails to cast to
number), the other side is cast to string, causing the types to follow
these rules:
integer: the string representation of the integer (e.g. "0", "-4" or
"123")
float: the string representation of the floating point number,
represented in one and only one particular format, preferably just the
%.f format.
boolean: cast to integer, cast to string (so true becomes 1, becomes
"1"; false becomes 0 becomes "0")
array: "array" causing a notice
object: "object" causing a notice, or calling the __toString method if
defined.
The oppposing problem is a non-generic way of handling any other
comparison. As a rule, we could state that any other comparison -if both
sides of different type- is handled the way it is in the current PHP
version. If they are of the same type, the == operator should act the
same as the === operator.
This is, as i am very sure, easily realized.
Please do not hesitate to ask me any questions through mail.
[2007-11-15 16:27:02] ken at smallboxsoftware dot net
Description:
Casting during comparison should only happen if values of different
types are being compared.
For example: "42" == "+42" should not return true.
This result is not very intuitive and probably leads to a number of
subtle errors in various scripts.
Reproduce code:
---
";
echo "Should Return False:".((string) "400" == (string) "+400")."";
echo "Does Return False:".("400" === "+400")."";
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=43304&edit=1
