Req #43236 [Com]: "if set" and "if not set" functions (ifset, ifnset)
Edit report at https://bugs.php.net/bug.php?id=43236&edit=1 ID: 43236 Comment by: jay-php at vengefulstapler dot com Reported by:zyss at mail dot zp dot ua Summary:"if set" and "if not set" functions (ifset, ifnset) Status: Not a bug 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: johannes, I haven't had a chance to test out ?: yet but someone else said that $val = $var['foo'] ?: ''; would still throw a notice if $var['foo'] was not set. If that is true, then it would still be nice to have something like what is described here. Previous Comments: [2007-11-10 21:38:29] johan...@php.net PHP 6 has the "?:" operator ($result = $foo ?: $bar;) which is close to your request and which will most likely be merged back to 5.3. [2007-11-10 20:32:33] zyss at mail dot zp dot ua Description: PHP programmers often need to check if certain variable is set when assigning its value to other variable or using it in expression. For example: $item_id = isset($_POST['item_id']) ? $_POST['item_id'] : null; which is quite unreadable. It would be much easier to write such things if there are function ifnset(mixed $value, mixed $alt) (If Not Set) which returns $value if $valus is set or $alt otherwise. Example above could be replaced with: $item_id = ifnset($_POST['item_id'], null); or, if another function is added - ifset - which returns null if its argument is not set or not defined: $item_id = ifset($_POST['item_id']); Similar function exists in MySQL (http://dev.mysql.com/doc/refman/5.1/en/control-flow-functions.html#function_ifnull) which makes life much easier when working with MySQL. It is not possible to implement this function in PHP because when undefined or unset variable is passed as function argument PHP emits warning. Although warnings could be suppressed with @ it significantly slows down performance when such situation happens. Besides debugger catches all suppressed warnings anyway. Thanks. -- Edit this bug report at https://bugs.php.net/bug.php?id=43236&edit=1
[PHP-BUG] Req #52626 [NEW]: New magic method for procedural calls on object.
From:
Operating system: *
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:New magic method for procedural calls on object.
Description:
Classic style:
Object style:
ksort();
$oa->is_array(); //implemented in ObjArray
?>
But what if :
(SplTypes project is dead and I need object types.)
Now it is not possible to control, what functions are executed on object.
If a language function is used on a object, php would
Variant 1) try to call object function of the same name,
Variant 2) call magic method __callOnObject if exists
Both variants can be implemented together.
Possible problem in variant 1)
Programmer would need to take care, to really implement exact same
structure of parameters, with all optional parameters, elze it would throw
errors on different arguments.
There could by a variant 1a) where, called function doesn't list all
arguments, but passes an array of arguments. But that would make object
calls too different from procedural.
Test script:
---
Variant 1)
class ObjArray extends ArrayIterator{
public function is_array( $var ){
return is_array( $this->storage );
}
public function is_object( $var ){
return is_object( $this->storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Variant 2)
class ObjArray extends ArrayIterator{
public function __callOnObject( $calledFunction, $params ){
switch $calledFunction {
case "is_array":
return $this->is_array( $params[0] );
break;
case "is_object":
return $this->is_object( $params[0] );
break;
default:
return $calledFunction( insert_params_irrelevant_how( $params ) );
}
}
public function is_array( $var ){
return is_array( $this->storage );
}
public function is_object( $var ){
return is_object( $this->storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Expected result:
Variant 1)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj->is_array( $obj ) );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj->is_object( $obj ) );
bool(false)
Variant 2)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj->__callOnObject( "is_array", Array(
$obj ) ) );
//swith/case finds function is_array and calls $obj->is_array( $obj );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj->__callOnObject( "is_object", Array(
$obj ) ) );
//swith/case finds function is_object and calls $obj->is_object( $obj );
bool(false)
Actual result:
--
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
bool(false)
//var_dump( is_object( $obj ) );
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=52626&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52626&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52626&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52626&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52626&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52626&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52626&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52626&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52626&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52626&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52626&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52626&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52626&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52626&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52626&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52626&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52626&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52626&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52626&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52626&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52626&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52626&r=mys
[PHP-BUG] Bug #51733 [NEW]: SQLite3::exec() fails with disk I/O error
From:
Operating system: Ubuntu 10.04, FreeBSD 8
PHP version: 5.3.2
Package: SQLite related
Bug Type: Bug
Bug description:SQLite3::exec() fails with disk I/O error
Description:
I've tested this problem and it is duplicable on Ubuntu 10.04 and FreeBSD
8, both with 5.3.2 installed (from apt-get/ports). I also did a build of
5.3.2 from source to test this and it failed in the same way.
The problem comes when you try to create a table in a newly created
database when using the SQLite3 class. The empty db is created without
error and when you then try to create a table, you get the following
error:
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line 1
This is the same error in all builds on all OSes.
Test script:
---
$ php -a
php > $s = new SQLite3('/home/jdeiman/tmp/php.db', SQLITE3_OPEN_CREATE);
php > $ret = $s->exec('CREATE table testing (id integer)');
PHP Warning: SQLite3::exec(): disk I/O error in php shell code on line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=51733&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51733&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51733&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51733&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51733&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51733&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51733&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51733&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51733&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51733&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51733&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51733&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51733&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51733&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51733&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51733&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51733&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51733&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51733&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51733&r=mysqlcfg
#49594 [Bgs]: POSIX regex are important
ID: 49594
User updated by: jay at phpcourses dot ca
Reported By: jay at phpcourses dot ca
Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.3.0
New Comment:
ok thank you
it's troublesome for many of us, but unavoidable i guess
Previous Comments:
[2009-10-01 22:03:13] ras...@php.net
We did not write the regex implementation. We rely on 3rd-party
libraries for everything in PHP. If a POSIX-compatible library that
supports Unicode magically appears, we can consider it, but as of right
now that does not exist and we are not going to write one. I doubt any
of the other scripting languages are going to do that either. Python
and Ruby both rely on PCRE as well, so we all support the same type of
regular expressions.
The responsible thing for us to do, given the state of regex libraries,
is to let users know that Unicode is the future and their current POSIX
regular expressions is not going to work in this Unicode world and they
need to plan for that.
I am sorry you do not agree with that, but that is the state of things
currently.
[2009-10-01 21:59:06] jay at phpcourses dot ca
then make ereg() work with preg_match()
so our code is not garbage
when php6 comes out, millions of servers get upgraded, and millions of
scripts will no longer function.
a mistake
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
[2009-10-01 21:56:09] paj...@php.net
It won't be available in php6 because ereg does not work with Unicode.
Simple. Has PHP6 been released yet? or is it getting anywhere close to
be released? No and no.
And php 5.x still has many years to live, given that you had already
almost a decade to be ready and that you get 5 more years or so using
error_reporting EOD.
[2009-10-01 21:49:09] jay at phpcourses dot ca
you first
This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP
6.0.0. Relying on this feature is highly discouraged.
[2009-10-01 21:30:13] paj...@php.net
Can you please do your homework prior to post to php.net's bug
reports?
Using PHP 5.3.0/svn:
> php -r "error_reporting(E_ALL); ereg('POSIX');"
Deprecated: Function ereg() is deprecated in Command line code on line
1
> php -r "error_reporting(E_ALL ^ E_DEPRECATED); ereg('POSIX',
'foo');"
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/49594
--
Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594
User updated by: jay at phpcourses dot ca
Reported By: jay at phpcourses dot ca
Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.3.0
New Comment:
then make ereg() work with preg_match()
so our code is not garbage
when php6 comes out, millions of servers get upgraded, and millions of
scripts will no longer function.
a mistake
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
unsubscribe
Previous Comments:
[2009-10-01 21:56:09] paj...@php.net
It won't be available in php6 because ereg does not work with Unicode.
Simple. Has PHP6 been released yet? or is it getting anywhere close to
be released? No and no.
And php 5.x still has many years to live, given that you had already
almost a decade to be ready and that you get 5 more years or so using
error_reporting EOD.
[2009-10-01 21:49:09] jay at phpcourses dot ca
you first
This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP
6.0.0. Relying on this feature is highly discouraged.
[2009-10-01 21:30:13] paj...@php.net
Can you please do your homework prior to post to php.net's bug
reports?
Using PHP 5.3.0/svn:
> php -r "error_reporting(E_ALL); ereg('POSIX');"
Deprecated: Function ereg() is deprecated in Command line code on line
1
> php -r "error_reporting(E_ALL ^ E_DEPRECATED); ereg('POSIX',
'foo');"
--------
[2009-10-01 21:25:53] jay at phpcourses dot ca
nobody answered the original query
WHY stop supporting parts of the api all of a sudden?
it does NO harm leaving it in, as in ZERO
it DOES harm taking it out
--------
[2009-10-01 21:25:03] jay at phpcourses dot ca
i can't
see, "marked for deprecation" is different than "will no longer be
supported in 5.3"
i'm helping php avoid big mistakes
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/49594
--
Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594
User updated by: jay at phpcourses dot ca
Reported By: jay at phpcourses dot ca
Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.3.0
New Comment:
you first
This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP
6.0.0. Relying on this feature is highly discouraged.
Previous Comments:
[2009-10-01 21:30:13] paj...@php.net
Can you please do your homework prior to post to php.net's bug
reports?
Using PHP 5.3.0/svn:
> php -r "error_reporting(E_ALL); ereg('POSIX');"
Deprecated: Function ereg() is deprecated in Command line code on line
1
> php -r "error_reporting(E_ALL ^ E_DEPRECATED); ereg('POSIX',
'foo');"
--------
[2009-10-01 21:25:53] jay at phpcourses dot ca
nobody answered the original query
WHY stop supporting parts of the api all of a sudden?
it does NO harm leaving it in, as in ZERO
it DOES harm taking it out
--------
[2009-10-01 21:25:03] jay at phpcourses dot ca
i can't
see, "marked for deprecation" is different than "will no longer be
supported in 5.3"
i'm helping php avoid big mistakes
----
[2009-10-01 18:08:49] paj...@php.net
Jay, disable E_DEPRECATED and be happy. Now go back to your usual
activities, thanks.
----
[2009-10-01 17:48:58] jay at phpcourses dot ca
i need to talk to someone more senior/experienced
i write 5000 - 1 php scripts a year, most of which use posix regex
and i don't need a junior telling me "we are not forcing you to upgrade
to php 5.3; keep 5.2 forever"
only a newbie would say that
my clients' scripts are on 1000s of servers around the world
php could also remove support for the pow() function, since there are
alternative ways of raising numbers to powers, but like the ereg()
support, they'd f*ck millions of developer worldwide
in short:
keep ereg() == no problems
scrap ereg() == problems
so why scrap API support?
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/49594
--
Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594 User updated by: jay at phpcourses dot ca Reported By: jay at phpcourses dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0 New Comment: nobody answered the original query WHY stop supporting parts of the api all of a sudden? it does NO harm leaving it in, as in ZERO it DOES harm taking it out Previous Comments: [2009-10-01 21:25:03] jay at phpcourses dot ca i can't see, "marked for deprecation" is different than "will no longer be supported in 5.3" i'm helping php avoid big mistakes [2009-10-01 18:08:49] paj...@php.net Jay, disable E_DEPRECATED and be happy. Now go back to your usual activities, thanks. -------- [2009-10-01 17:48:58] jay at phpcourses dot ca i need to talk to someone more senior/experienced i write 5000 - 1 php scripts a year, most of which use posix regex and i don't need a junior telling me "we are not forcing you to upgrade to php 5.3; keep 5.2 forever" only a newbie would say that my clients' scripts are on 1000s of servers around the world php could also remove support for the pow() function, since there are alternative ways of raising numbers to powers, but like the ereg() support, they'd f*ck millions of developer worldwide in short: keep ereg() == no problems scrap ereg() == problems so why scrap API support? ---- [2009-10-01 16:24:21] jay at phpcourses dot ca you are mistaken again posix regex are ALSO everywhere! i have written probably 1 scripts, i won't be updating them to use your favorite version of regex you have once again missed the point: do not throw away support for APIs YOU keep the regex, and let US choose that's community-driven, open-source software trust me on this [2009-10-01 15:19:24] bever...@php.net No, you think it's a mistake. In fact, the PCRE library offers more features, (mostly) better performance and is used in other programming languages as well (Java, Javascript, .NET). On top of that, it offers more consistent syntax. After all, no one is forcing you to upgrade your PHP version. It will remain available throughout the 5.x versions. Just don't update to PHP 6 if it really is a problem. Either way, you've got more than enough time to update any scripts or sites. 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/49594 -- Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594 User updated by: jay at phpcourses dot ca Reported By: jay at phpcourses dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0 New Comment: i can't see, "marked for deprecation" is different than "will no longer be supported in 5.3" i'm helping php avoid big mistakes Previous Comments: [2009-10-01 18:08:49] paj...@php.net Jay, disable E_DEPRECATED and be happy. Now go back to your usual activities, thanks. -------- [2009-10-01 17:48:58] jay at phpcourses dot ca i need to talk to someone more senior/experienced i write 5000 - 1 php scripts a year, most of which use posix regex and i don't need a junior telling me "we are not forcing you to upgrade to php 5.3; keep 5.2 forever" only a newbie would say that my clients' scripts are on 1000s of servers around the world php could also remove support for the pow() function, since there are alternative ways of raising numbers to powers, but like the ereg() support, they'd f*ck millions of developer worldwide in short: keep ereg() == no problems scrap ereg() == problems so why scrap API support? ---- [2009-10-01 16:24:21] jay at phpcourses dot ca you are mistaken again posix regex are ALSO everywhere! i have written probably 1 scripts, i won't be updating them to use your favorite version of regex you have once again missed the point: do not throw away support for APIs YOU keep the regex, and let US choose that's community-driven, open-source software trust me on this [2009-10-01 15:19:24] bever...@php.net No, you think it's a mistake. In fact, the PCRE library offers more features, (mostly) better performance and is used in other programming languages as well (Java, Javascript, .NET). On top of that, it offers more consistent syntax. After all, no one is forcing you to upgrade your PHP version. It will remain available throughout the 5.x versions. Just don't update to PHP 6 if it really is a problem. Either way, you've got more than enough time to update any scripts or sites. [2009-10-01 15:16:20] paj...@php.net You completely ignore the options you have, that's your rights. There is no bug, there is no issue > bogus. If you don't know how to use the error_reporting flags, please read the manual or ask for support in one of the numerous support channels. Thanks for your understanding. 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/49594 -- Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594 User updated by: jay at phpcourses dot ca Reported By: jay at phpcourses dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0 New Comment: i need to talk to someone more senior/experienced i write 5000 - 1 php scripts a year, most of which use posix regex and i don't need a junior telling me "we are not forcing you to upgrade to php 5.3; keep 5.2 forever" only a newbie would say that my clients' scripts are on 1000s of servers around the world php could also remove support for the pow() function, since there are alternative ways of raising numbers to powers, but like the ereg() support, they'd f*ck millions of developer worldwide in short: keep ereg() == no problems scrap ereg() == problems so why scrap API support? Previous Comments: ---- [2009-10-01 16:24:21] jay at phpcourses dot ca you are mistaken again posix regex are ALSO everywhere! i have written probably 1 scripts, i won't be updating them to use your favorite version of regex you have once again missed the point: do not throw away support for APIs YOU keep the regex, and let US choose that's community-driven, open-source software trust me on this [2009-10-01 15:19:24] bever...@php.net No, you think it's a mistake. In fact, the PCRE library offers more features, (mostly) better performance and is used in other programming languages as well (Java, Javascript, .NET). On top of that, it offers more consistent syntax. After all, no one is forcing you to upgrade your PHP version. It will remain available throughout the 5.x versions. Just don't update to PHP 6 if it really is a problem. Either way, you've got more than enough time to update any scripts or sites. [2009-10-01 15:16:20] paj...@php.net You completely ignore the options you have, that's your rights. There is no bug, there is no issue > bogus. If you don't know how to use the error_reporting flags, please read the manual or ask for support in one of the numerous support channels. Thanks for your understanding. ---- [2009-10-01 15:03:36] jay at phpcourses dot ca you've missed the point entirely unlike C and Java etc php has gone the route of "most of your old scripts will no longer work when you upgrade php" it's a mistake there is no point in trying to defend it, it's a known mistake that's made many of us upset for example, i teach php at a university and at a college, in addition to being a contractor and developing my own sites such as torqueinvoicing.com and we all know it's a mistake [2009-10-01 14:29:34] paj...@php.net The api is still usable as it is emulated by pcre. If you really like to use it for the rest of your life, disable the deprecated warnings and be done with that. 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/49594 -- Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594 User updated by: jay at phpcourses dot ca Reported By: jay at phpcourses dot ca Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.3.0 New Comment: you are mistaken again posix regex are ALSO everywhere! i have written probably 1 scripts, i won't be updating them to use your favorite version of regex you have once again missed the point: do not throw away support for APIs YOU keep the regex, and let US choose that's community-driven, open-source software trust me on this Previous Comments: [2009-10-01 15:19:24] bever...@php.net No, you think it's a mistake. In fact, the PCRE library offers more features, (mostly) better performance and is used in other programming languages as well (Java, Javascript, .NET). On top of that, it offers more consistent syntax. After all, no one is forcing you to upgrade your PHP version. It will remain available throughout the 5.x versions. Just don't update to PHP 6 if it really is a problem. Either way, you've got more than enough time to update any scripts or sites. [2009-10-01 15:16:20] paj...@php.net You completely ignore the options you have, that's your rights. There is no bug, there is no issue > bogus. If you don't know how to use the error_reporting flags, please read the manual or ask for support in one of the numerous support channels. Thanks for your understanding. -------- [2009-10-01 15:03:36] jay at phpcourses dot ca you've missed the point entirely unlike C and Java etc php has gone the route of "most of your old scripts will no longer work when you upgrade php" it's a mistake there is no point in trying to defend it, it's a known mistake that's made many of us upset for example, i teach php at a university and at a college, in addition to being a contractor and developing my own sites such as torqueinvoicing.com and we all know it's a mistake [2009-10-01 14:29:34] paj...@php.net The api is still usable as it is emulated by pcre. If you really like to use it for the rest of your life, disable the deprecated warnings and be done with that. -------- [2009-10-01 14:25:16] jay at phpcourses dot ca recommended? simply not true all it ever says is "Note: preg_match(), which uses a Perl-compatible regular expression syntax, is often a faster alternative to ereg(). " plus, posix regex have a life of their own, independent of php at my engineering firm we use posix regex exclusively php is making a mistake abandoning parts of its api. a mistake. 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/49594 -- Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Bgs]: POSIX regex are important
ID: 49594
User updated by: jay at phpcourses dot ca
Reported By: jay at phpcourses dot ca
Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.3.0
New Comment:
you've missed the point entirely
unlike C and Java etc
php has gone the route of "most of your old scripts will no longer work
when you upgrade php"
it's a mistake
there is no point in trying to defend it, it's a known mistake that's
made many of us upset
for example, i teach php at a university and at a college, in addition
to being a contractor and developing my own sites such as
torqueinvoicing.com and we all know it's a mistake
Previous Comments:
[2009-10-01 14:29:34] paj...@php.net
The api is still usable as it is emulated by pcre. If you really like
to use it for the rest of your life, disable the deprecated warnings and
be done with that.
----
[2009-10-01 14:25:16] jay at phpcourses dot ca
recommended?
simply not true
all it ever says is "Note: preg_match(), which uses a Perl-compatible
regular expression syntax, is often a faster alternative to ereg(). "
plus, posix regex have a life of their own, independent of php
at my engineering firm we use posix regex exclusively
php is making a mistake abandoning parts of its api.
a mistake.
[2009-10-01 04:44:08] a at b dot c dot de
For the past eight years PHP has recommended using the PCRE regex
functions. This has been noted on, for example, the manual page for
ereg().
--------
[2009-09-18 19:53:09] jay at phpcourses dot ca
Description:
why is PHP deprecating the pervasive, very important POSIX regex
support? nearly every script i have ever written and/or taught in the
past 8 years uses posix regex, and now it will ALL be useless? my
customers will be disappointed and their code won't work. just LEAVE THE
POSIX REGEX ALONE.
Reproduce code:
---
ereg('posix')
Expected result:
success
Actual result:
--
the single worst mistake php has ever made
--
Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [Opn]: POSIX regex are important
ID: 49594
User updated by: jay at phpcourses dot ca
Reported By: jay at phpcourses dot ca
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.3.0
New Comment:
recommended?
simply not true
all it ever says is "Note: preg_match(), which uses a Perl-compatible
regular expression syntax, is often a faster alternative to ereg(). "
plus, posix regex have a life of their own, independent of php
at my engineering firm we use posix regex exclusively
php is making a mistake abandoning parts of its api.
a mistake.
Previous Comments:
[2009-10-01 04:44:08] a at b dot c dot de
For the past eight years PHP has recommended using the PCRE regex
functions. This has been noted on, for example, the manual page for
ereg().
[2009-09-18 19:53:09] jay at phpcourses dot ca
Description:
why is PHP deprecating the pervasive, very important POSIX regex
support? nearly every script i have ever written and/or taught in the
past 8 years uses posix regex, and now it will ALL be useless? my
customers will be disappointed and their code won't work. just LEAVE THE
POSIX REGEX ALONE.
Reproduce code:
---
ereg('posix')
Expected result:
success
Actual result:
--
the single worst mistake php has ever made
--
Edit this bug report at http://bugs.php.net/?id=49594&edit=1
#49594 [NEW]: POSIX regex are important
From: jay at phpcourses dot ca
Operating system: all
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: POSIX regex are important
Description:
why is PHP deprecating the pervasive, very important POSIX regex support?
nearly every script i have ever written and/or taught in the past 8 years
uses posix regex, and now it will ALL be useless? my customers will be
disappointed and their code won't work. just LEAVE THE POSIX REGEX ALONE.
Reproduce code:
---
ereg('posix')
Expected result:
success
Actual result:
--
the single worst mistake php has ever made
--
Edit bug report at http://bugs.php.net/?id=49594&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49594&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49594&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49594&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49594&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49594&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49594&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49594&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49594&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49594&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49594&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49594&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49594&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49594&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49594&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49594&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49594&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49594&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49594&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49594&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49594&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49594&r=mysqlcfg
#49121 [Opn]: private var accessible from static class
ID: 49121
User updated by: jay at jay dot cz
Reported By: jay at jay dot cz
Status: Open
Bug Type: Class/Object related
Operating System: ubuntu linux
PHP Version: 5.2.10
New Comment:
"Private limits visibility only to the class that defines the item."
It is not (static) FOO that defines that private item, but it is $foo
instance that defines it.
If it is a "feature", then it is pretty big hole, that static class has
full access to all properties of all instances created from it.
And if it is meant, that it's not limited by "instance" but by "class",
then also two instances from the same class should be able to access
each others private properties.
This behavior was reported also in comment
http://php.net/manual/en/language.oop5.visibility.php#69104
Previous Comments:
------------
[2009-07-31 12:42:08] jay at jay dot cz
Description:
Private property of initialized class, is accessible from static
version of the same class.
Reproduce code:
---
class FOO {
private $bar = 0;
private static $instance = false;
public static function get_instance(){
if(self::$instance === false) self::$instance = new FOO;
return self::$instance;
}
public static function set_bar( $b ){
$foo = FOO::get_instance();
$foo->bar = $b;
}
public static function dump_bar(){
$foo = FOO::get_instance();
echo $foo->bar;
}
}
FOO::set_bar( 1 );
FOO::dump_bar();
$foo = FOO::get_instance();
echo $foo->bar;
Expected result:
Fatal error: Cannot access private property FOO::$bar in
/var/www/index.php on line 10
I should not be able to write to a private property from "outside".
(Even thou it's the same code for both classes (static and
initialized).)
Actual result:
--
1
Fatal error: Cannot access private property FOO::$bar in
/var/www/index.php on line 20
Well, I can write to the private property and I can read it, from
inside the static.
The error is when I try to access it from completely "outside". And
that error is correct.
Same result for private and protected.
--
Edit this bug report at http://bugs.php.net/?id=49121&edit=1
#49121 [NEW]: private var accessible from static class
From: jay at jay dot cz
Operating system: ubuntu linux
PHP version: 5.2.10
PHP Bug Type: Class/Object related
Bug description: private var accessible from static class
Description:
Private property of initialized class, is accessible from static version
of the same class.
Reproduce code:
---
class FOO {
private $bar = 0;
private static $instance = false;
public static function get_instance(){
if(self::$instance === false) self::$instance = new FOO;
return self::$instance;
}
public static function set_bar( $b ){
$foo = FOO::get_instance();
$foo->bar = $b;
}
public static function dump_bar(){
$foo = FOO::get_instance();
echo $foo->bar;
}
}
FOO::set_bar( 1 );
FOO::dump_bar();
$foo = FOO::get_instance();
echo $foo->bar;
Expected result:
Fatal error: Cannot access private property FOO::$bar in
/var/www/index.php on line 10
I should not be able to write to a private property from "outside". (Even
thou it's the same code for both classes (static and initialized).)
Actual result:
--
1
Fatal error: Cannot access private property FOO::$bar in
/var/www/index.php on line 20
Well, I can write to the private property and I can read it, from inside
the static.
The error is when I try to access it from completely "outside". And that
error is correct.
Same result for private and protected.
--
Edit bug report at http://bugs.php.net/?id=49121&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49121&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49121&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49121&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49121&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49121&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49121&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49121&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49121&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49121&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49121&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49121&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49121&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49121&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49121&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49121&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49121&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49121&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49121&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49121&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49121&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49121&r=mysqlcfg
#36646 [Com]: foreach($_SESSION as $key => $value) unset($_SESSION[$key]) crashes apache2
ID: 36646
Comment by: jay at websynergia dot com
Reported By: christian dot cal at gmx dot de
Status: No Feedback
Bug Type: Session related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
$_SESSION = array();
Why not just do the above if you want to clear the session array?
It has always worked for me regardless.
Previous Comments:
[2007-03-30 22:16:55] grafelbd at telstar-online dot net
I am using PHP 5.2.1 and I have tested this same issue with an array of
15 items with randomly generated strings, and this bug did not affect
me.
I tried using PHP 5.2.1 both as an Apache module (running Apache
2.0.59) and as a FastCGI but was unable to reproduce this error in
either setup.
I believe this bug might have been resolved in PHP 5.2.1 ? Unless all
of you are referring to Apache 2.2.x, which I have not tested.
[2007-03-30 00:17:05] no at email dot here
No crash for me, but I confirm the bug with php version 5.2.0 under
windows : no unset the variables
The proposed solution is OK :
$helper=&$_SESSION;
foreach ($helper as $key => $value){
unset($helper[$key]);
}
Thanks
[2006-09-18 13:53:29] s dot stok at rollerscapes dot net
Im ussing the latest version of php5.2, and i also haffing this
problem.
The whird thing is that on my linux box everything works fine,only on
windows it fails to work.
Only the workaround makes it work.
[2006-08-27 01:12:36] joe at gmail dot com
Actually to clarify, it doesn't crash Apache on my computer, but it
doesn't unset the variables!
[2006-08-27 01:09:31] joe at gmail dot com
I'm running 5.1.6 and I have this problem... it still hasn't been
fixed!
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/36646
--
Edit this bug report at http://bugs.php.net/?id=36646&edit=1
#41876 [NEW]: bindParam() and bindValue() do not work with MySQL MATCH () AGAINST ()
From: jay at mysql dot com
Operating system: Linux 2.6.20
PHP version: 5.2.3
PHP Bug Type: PDO related
Bug description: bindParam() and bindValue() do not work with MySQL MATCH ()
AGAINST ()
Description:
When using the MATCHES(cols...) AGAINST (phrase) construct in MySQL using
PDO prepared statements and bound parameters, the binding does not
recognize the "?" within the AGAINST ().
Reproduce code:
---
$pdo= new
PDO("mysql:host=localhost;dbname=some_db","some_user","some_pass");
$sql= "SELECT * FROM some_table WHERE MATCH(some_col) AGAINST (?)";
$statement= $pdo->prepare($sql);
$statement->bindValue(1, "some search phrase");
$statement->execute(); // Will error here with "invalid parameter number,
no parameters bound"
If you replace the ? in the SQL statement with the string search phrase
value, it will work fine.
Expected result:
Expect to bind the value into the unnamed parameter and execute properly.
Actual result:
--
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY093]: Invalid parameter number: no parameters were bound in XXX
--
Edit bug report at http://bugs.php.net/?id=41876&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41876&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41876&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41876&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41876&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41876&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41876&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41876&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41876&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41876&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41876&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41876&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41876&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41876&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41876&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41876&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41876&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41876&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41876&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41876&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41876&r=mysqlcfg
#41868 [Com]: Error with multiple instances of same named parameter
ID: 41868
Comment by: jay at mysql dot com
Reported By: nick+phpbugs at ag dot arizona dot edu
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.3
New Comment:
This was unsupported behaviour and only worked by accident before
5.2.1. Use bindValue() instead. For more information, see here:
http://paul-m-jones.com/blog/?p=243
Cheers,
Jay
Previous Comments:
[2007-07-02 05:10:28] nick+phpbugs at ag dot arizona dot edu
Description:
A named parameter should be able to be included more than once in a
query, but bound only once. Instead, when code like the given is
executed, the following error is produced:
Warning: PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY093]: Invalid parameter number: number of bound variables
does not match number of tokens in /home/njm/public_html/test.php on
line 7
Reproduce code:
---
$db = new PDO('mysql:host=localhost;dbname=test', 'test', 'whatever');
$db->exec('CREATE TABLE foo (a INT, b INT)');
$sth = $db->prepare('INSERT INTO foo (a, b) VALUES (:value, :value)');
$sth->bindParam(':value', 10);
$sth->execute();
Expected result:
A row inserted into foo where a = b = 10.
--
Edit this bug report at http://bugs.php.net/?id=41868&edit=1
#40688 [Com]: php configure error
ID: 40688 Comment by: jay at drummondsoftware dot com Reported By: ryo dot wong at i010 dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: centos 4.4 i386 PHP Version: 5.2.1 New Comment: I'm running on centOS 4.4 and this was happening to me when I tried to compile PHP with the -with-xsl=/usr/bin option. I needed to add libgcrypt-devel to the OS. As root yum install libgcrypt-devel This also added a dependency package of libgpg-error-devel Give it a try. Previous Comments: [2007-03-18 16:10:24] jay at drummondsoftware dot com I'm running on centOS 4.4 and this was happening to me when I tried to compile PHP with the -with-xsl=/usr/bin option. I needed to add libgcrypt-devel to the OS. yum install libgcrypt-devel This also added a dependency package of libgpg-error-devel Give it a try. [2007-03-10 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-03-02 08:01:08] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2007-03-02 03:36:50] ryo dot wong at i010 dot com Description: /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Reproduce code: --- /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Expected result: /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Actual result: -- /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=40688&edit=1
#40688 [Com]: php configure error
ID: 40688 Comment by: jay at drummondsoftware dot com Reported By: ryo dot wong at i010 dot com Status: No Feedback Bug Type: *Configuration Issues Operating System: centos 4.4 i386 PHP Version: 5.2.1 New Comment: I'm running on centOS 4.4 and this was happening to me when I tried to compile PHP with the -with-xsl=/usr/bin option. I needed to add libgcrypt-devel to the OS. yum install libgcrypt-devel This also added a dependency package of libgpg-error-devel Give it a try. Previous Comments: [2007-03-10 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-03-02 08:01:08] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2007-03-02 03:36:50] ryo dot wong at i010 dot com Description: /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Reproduce code: --- /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Expected result: /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Actual result: -- /usr/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=40688&edit=1
#32463 [Asn]: mhash implementation of Tiger incorrect?
ID: 32463 Updated by: [EMAIL PROTECTED] Reported By: Keamos at gmail dot com Status: Assigned Bug Type: mhash related Operating System: Windows XP SP2 PHP Version: 4.3.10 Assigned To: sas New Comment: This isn't really a bug, it's more of a different implementation/interpretation of the Tiger algorithm. The test vectors provided on the Tiger homepage provide the output hash in little endian, while the testtiger reference implementation at the site outputs the hash in big endian. Both outputs are correct, I guess, it's just the ordering of the bytes that changes. I'll leave the bug status as is so Sascha can see it and give a more definitive anwser than I can, but I don't think it's a bug per se. Previous Comments: [2005-03-26 18:03:43] [EMAIL PROTECTED] Assigning to Sascha, the maintainer of this extension. [2005-03-26 14:51:39] Keamos at gmail dot com Description: Mhash fails the Tiger test vectors found at http://www.cs.technion.ac.il/~biham/Reports/Tiger/test-vectors-nessie-format.dat Reproduce code: --- Since the reproduce code is more than twenty lines, find it at http://pastebin.ca/8273 -- Edit this bug report at http://bugs.php.net/?id=32463&edit=1
#31903 [NEW]: erorr
From: jay at keylex dot om Operating system: ms 2000 PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: erorr Description: hi im having a problem with php when i go to my site at keylex.com/support/index.php i get this error No input file specified. please resolve this issue ASAP or you can call me at (718)701-4036 i preffered calling -- Edit bug report at http://bugs.php.net/?id=31903&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31903&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31903&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31903&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31903&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31903&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31903&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31903&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31903&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31903&r=support Expected behavior: http://bugs.php.net/fix.php?id=31903&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31903&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31903&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31903&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31903&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31903&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31903&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31903&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31903&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31903&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31903&r=mysqlcfg
#30580 [NEW]: GD imagecolorallocate does not work after many allocations
From: jay at kuantic dot com
Operating system: Linux fedora core 1
PHP version: 5.0.2
PHP Bug Type: GD related
Bug description: GD imagecolorallocate does not work after many allocations
Description:
After several color allocations, imagecolorallocate seems to no work
anymore. See code sample (illogical but point at the problem).
Reproduce code:
---
function letter($l, $x, $y, $img) {
$color1 = imagecolorallocate($img, 190, 190, 190);
imagestring ($img, 1, $x+1, $y+1, $l, $color1);
$color2 = imagecolorallocate($img, 190, 190, 190);
imagestring ($img, 1, $x-1, $y-1, $l, $color2);
$color3 = in a picture.($img, 255, 0, 0);
imagestring ($img, 1, $x, $y, $l, $color3);
}
$image = @imagecreate (1200, 500);
$background_color = imagecolorallocate ($image, 255, 255, 255);
for ($i = 0; $i < 100; $i++){
letter($i, $i*12, 50, $image);
}
header ("Content-type: image/png");
imagepng ($image);
imagedestroy($image);
Expected result:
expected : display 1 to 100 red digits with gray shadow in a picture.
Actual result:
--
result : displays 1 to 84 red digits with gray shadow in a picture. After
84, digits and shadows are all red. imagecolorallocate seems to not work
anymore.
--
Edit bug report at http://bugs.php.net/?id=30580&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30580&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30580&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30580&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30580&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30580&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30580&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30580&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30580&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30580&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30580&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30580&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30580&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30580&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30580&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30580&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30580&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30580&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30580&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30580&r=mysqlcfg
#27372 [Ver]: parse error loading browscap.ini at apache startup (new parser required)
ID: 27372
Updated by: [EMAIL PROTECTED]
Reported By: php-bug-NOSPAM-2004 at ryandesign dot com
Status: Verified
Bug Type: *General Issues
Operating System: *
PHP Version: 4CVS, 5CVS (2004-04-07)
New Comment:
This would have to be caught during module start up, but
what should be done about it? Have the parser crap out and
stop processing when this happens, leaving an error
message in the logs or on stderr or whatever? Spit out a
warning but continue processing? What assumptions should
be made about the screwed up entry, should it just be
discarded?
This should probably be in it's own bug report, btw, this
is a seperate issue from the original report. (The new
parser fixes the original bug report, but not this issue,
which may or may not be fixed, as it's kind of a problem
with the ini file itself, akin to calling a function with
infinite recursion...)
J
Previous Comments:
[2004-10-02 21:54:48] alexandre at alapetite dot remove dot net
Gary Keith has already (2004-10-02) kindly modified his browscap.ini in
order to prevent a specific crash about the Nutch browser. But the
browscap parser should anyway include a security: when one assign a
parent to the same parent in browscap.ini, there is an infinite loop
that should be prevented.
Example in browscap.ini:
[Nutch]
parent=Nutch
Then in a PHP script:
$browser=get_browser('Nutch');
Effect:
Infinite loop that takes 100% CPU forever.
[2004-08-31 21:22:34] [EMAIL PROTECTED]
I posted this on internals but I should probably add it to
the bug report, too...
A patch for this against HEAD is available at
http://bugs.tutorbuddy.com/download.php/browscap.patch.tar.gz
It contains the new parser (which goes into ext/standard)
and updates to the makefiles for *ix and win32. I've
tested the patch on linux and win2k, and I'd like to
commit to HEAD for inclusion in 5.1. Backporting to 5.0
would be nice, too, if possible.
J
[2004-02-26 18:32:25] php_bug_27372 at garykeith dot com
Hi, Derick.
Since there are so many people still using very early versions of 4.3.x
I know it will be a very long time before everyone upgrades to 5.* and
that means I'll be stuck in the same untenable situation I'm in right
now for a very long time.
Kindly remove the link to my website from your documentation page. It's
not fair to your users to refer them to a browscap.ini file that does
not work in PHP.
~gary.
[2004-02-26 16:37:33] [EMAIL PROTECTED]
Hey,
there will be no back-port to PHP 4.3, as it involves writing a whole
new parser, which is simply something that should not go into a bug-fix
only branch (and it is also very unlikely that there will be a 4.3.6
anyway).
Now, for PHP 5 that is obviously not a problem and we'll have to write
a new parser for it, which is not an easy task, and that takes time
too. I can't not guarantee in which time frame that happens though.
Derick
[2004-02-26 16:27:16] php_bug_27372 at garykeith dot com
Sniper, I see you deleted my messages again. And you still have not
replied to the e-mail I sent you days ago. That's why I'm posting this
here instead of via e-mail. It seems to be the only way to reach you.
Ryan and Jay have been hard at work on fixing the problems with
get_browser(). They made use of my 23,000 user agents database and with
a couple of exceptions their mods made get_browser() work perfectly. The
exceptions seem related to the ini parser that get_browser() apparently
shares with other parts of PHP.
Anyway, I have already toned down the anti-PHP rhetoric on my website
because of the hard work these two guys have been doing and was ready
to make some temporary changes to my browscap.ini file to accommodate
PHP.
But first I want some assurance from someone on the PHP team that this
parser issue will be addressed, soon. I'd like to see it worked into
version 5 and then maybe backported to to the 4.3 branch.
Is this something you can help me with? If you'd prefer to contact me
via e-mail and delete this message that's fine with me.
~gary.
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/27372
--
Edit this bug report at http://bugs.php.net/?id=27372&edit=1
#27372 [Ver]: parse error loading browscap.ini at apache startup (new parser required)
ID: 27372 Updated by: [EMAIL PROTECTED] Reported By: php-bug-NOSPAM-2004 at ryandesign dot com Status: Verified Bug Type: *General Issues Operating System: * PHP Version: 4CVS, 5CVS (2004-04-07) New Comment: I posted this on internals but I should probably add it to the bug report, too... A patch for this against HEAD is available at http://bugs.tutorbuddy.com/download.php/browscap.patch.tar.gz It contains the new parser (which goes into ext/standard) and updates to the makefiles for *ix and win32. I've tested the patch on linux and win2k, and I'd like to commit to HEAD for inclusion in 5.1. Backporting to 5.0 would be nice, too, if possible. J Previous Comments: [2004-02-26 18:32:25] php_bug_27372 at garykeith dot com Hi, Derick. Since there are so many people still using very early versions of 4.3.x I know it will be a very long time before everyone upgrades to 5.* and that means I'll be stuck in the same untenable situation I'm in right now for a very long time. Kindly remove the link to my website from your documentation page. It's not fair to your users to refer them to a browscap.ini file that does not work in PHP. ~gary. [2004-02-26 16:37:33] [EMAIL PROTECTED] Hey, there will be no back-port to PHP 4.3, as it involves writing a whole new parser, which is simply something that should not go into a bug-fix only branch (and it is also very unlikely that there will be a 4.3.6 anyway). Now, for PHP 5 that is obviously not a problem and we'll have to write a new parser for it, which is not an easy task, and that takes time too. I can't not guarantee in which time frame that happens though. Derick [2004-02-26 16:27:16] php_bug_27372 at garykeith dot com Sniper, I see you deleted my messages again. And you still have not replied to the e-mail I sent you days ago. That's why I'm posting this here instead of via e-mail. It seems to be the only way to reach you. Ryan and Jay have been hard at work on fixing the problems with get_browser(). They made use of my 23,000 user agents database and with a couple of exceptions their mods made get_browser() work perfectly. The exceptions seem related to the ini parser that get_browser() apparently shares with other parts of PHP. Anyway, I have already toned down the anti-PHP rhetoric on my website because of the hard work these two guys have been doing and was ready to make some temporary changes to my browscap.ini file to accommodate PHP. But first I want some assurance from someone on the PHP team that this parser issue will be addressed, soon. I'd like to see it worked into version 5 and then maybe backported to to the 4.3 branch. Is this something you can help me with? If you'd prefer to contact me via e-mail and delete this message that's fine with me. ~gary. [2004-02-26 15:39:37] php-bug-NOSPAM-2004 at ryandesign dot com There's also a user agent with "check&get" in its name. While this does not cause a parser error, PHP fills its name into the array as "0" instead of its actual name. I suspect this is also related to the special way ini files are currently handled, and that it doesn't like the "&" char in the user agent string, and that this should be addressed at the same time as the "!" issue. [2004-02-24 11:14:33] php_bug_27372 at garykeith dot com Oh, and the reason I cannot delimit certain values with double-quotes is because browscap.dll does not strip out the quotes. If I entered "Yahoo! Slurp" as a browser name then everyone using browscap.ini on IIS would see "Yahoo! Slurp", including the double quotes as the browser name. 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/27372 -- Edit this bug report at http://bugs.php.net/?id=27372&edit=1
#28920 [Opn->Bgs]: Problem with PHP's get_browser()
ID: 28920 Updated by: [EMAIL PROTECTED] Reported By: klaus_kuehne at t-online dot de -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Win 2000 PHP Version: 4.3.6 New Comment: . Previous Comments: [2004-06-28 07:12:29] klaus_kuehne at t-online dot de Sorry, there was no reason for my bug report: get_browser() returns an object, no array. But here is a little bug in the FOREACH-documentation: "foreach works only on arrays, and will issue an error when you try to use it on a variable with a different data type or an uninitialized variable." We ca see, it works on onjects, too. Klaus Kühne [2004-06-25 13:50:26] klaus_kuehne at t-online dot de Description: Hello, following happens in PHP 4.3.6: (1) $browser = get_browser(); foreach ($browser as $key => $val) print "$key = $val, "; delivers: ..., cookies = 1, ... (correctly) (2) $browser = get_browser(); print $browser["cookies"]; delivers NULL (3) $browser = get_browser(); $arr = array(); foreach ($browser as $key => $val) $arr[$key] = $val; print $arr["cookies"]; delivers 1. I don't understand the NULL-result of (2). Greetings Klaus Kühne -- Edit this bug report at http://bugs.php.net/?id=28920&edit=1
#28703 [Opn->Bgs]: browscap.ini : may be error in order of reg. expressions
ID: 28703 Updated by: [EMAIL PROTECTED] Reported By: andrew_chel at ua dot fm -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 4.3.4 New Comment: There have been various fixes for get_browser() that have been applied since PHP 4.3.4. Please try a more up-to-date version of PHP, like the recently released 4.3.7, as this problem has likely already been fixed. J Previous Comments: [2004-06-08 20:19:33] andrew_chel at ua dot fm Description: I got the latest version of the browsecap.ini file from http://www.garykeith.com/browsers/downloads.asp (link on this page was in PHP.chm documentation file) $HTTP_SERVER_VARS['HTTP_USER_AGENT'] is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) but get_browser() return netclr='' instead netclr='1' if I swap (expression with .NET CLR* become first) following lines in browscap.ini all work correctly and get_browser() return netclr='1': [Mozilla/4.0 (compatible; MSIE 6.0*;*Windows NT 5.0*)*] parent=IE 6.0 platform=Win2000 [Mozilla/4.0 (compatible; MSIE 6.0*;*Windows NT 5.0*.NET CLR*)*] parent=IE 6.0 platform=Win2000 netclr=True -- Edit this bug report at http://bugs.php.net/?id=28703&edit=1
#28545 [Opn->Bgs]: get_browser detecting spambot
ID: 28545 Updated by: [EMAIL PROTECTED] Reported By: gerwout at eigenwijze dot nl -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.6 New Comment: You'll have to contact the browscap.ini file maintainer for this sort of thing. See http://www.garykeith.com/ J Previous Comments: [2004-05-27 19:46:28] gerwout at eigenwijze dot nl Description: Maybe this isn't a PHP feature request, but more a browscap related featurerequest, but the manual refers to a special php browscap.ini file, so it could be added. Currently the get_browser function returns an object which contains crawler, very handy, because we can easily detect searchengines now :-) In my opinion the returned object should also contain the variable spambot. Now we can detect a spambot on a simulair way. -- Edit this bug report at http://bugs.php.net/?id=28545&edit=1
#27986 [Opn]: .lo unrecognized file suffix
ID: 27986 Updated by: [EMAIL PROTECTED] Reported By: sandduneinfo at earthlink dot net Status: Open Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4CVS, 5CVS (2004-04-16) New Comment: Have you tried the fix suggested here yet? http://marc.theaimsgroup.com/?l=php-install&m=104327038604878&w=2 I don't have access AIX so I have no idea if it works, but it's worth a shot... J Previous Comments: [2004-05-12 04:21:41] sandduneinfo at earthlink dot net OK here is the compile errors from last attempt. If I do not have this resolved by the end of the week the project is lost to perl. I have no defense it has been a month since I reported this to you. The first fixes I patched in repaired the unsigned integer - I web searched and it seems this .lo extension unrecognized has come up in older releases of AIX and was supposedly resolved in much older releases of php. Anyway for what its worth here is the detail of error output: cc: 1501-218 file ext/standard/formatted_print.lo contains an incorrect file suf fix cc: 1501-218 file ext/standard/fsock.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/head.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/html.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/image.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/info.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/iptc.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/lcg.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/link.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/mail.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/math.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/md5.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/metaphone.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/microtime.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/pack.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/pageinfo.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/parsedate.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/quot_print.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/rand.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/reg.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/soundex.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/string.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/scanf.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/syslog.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/type.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/uniqid.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/url.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/url_scanner.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/var.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/versioning.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/assert.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/strnatcmp.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/levenshtein.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/incomplete_class.lo contains an incorrect file su ffix cc: 1501-218 file ext/standard/url_scanner_ex.lo contains an incorrect file suff ix cc: 1501-218 file ext/standard/ftp_fopen_wrapper.lo contains an incorrect file s uffix cc: 1501-218 file ext/standard/http_fopen_wrapper.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/php_fopen_wrapper.lo contains an incorrect file s uffix cc: 1501-218 file ext/standard/credits.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/css.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/var_unserializer.lo contains an incorrect file su ffix cc: 1501-218 file ext/standard/ftok.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/aggregation.lo contains an incorrect file suffix cc: 1501-218 file ext/standard/sha1.lo contains an incorrect file suffix cc: 1501-218 file ext/tokenizer/tokenizer.lo contains an incorrect file suffix cc: 1501-218 file ext/xml/xml.lo contains an incorrect file suffix cc: 1501-218 file ext/xml/expat/xmlparse.lo contains an incorrect file suffix cc: 1501-218 file ext/xml/expat/xmlrole.lo contains an incorrect file suffix cc: 1501-218 file ext/xml/expat/xmltok.lo contains an incorrect file suffix cc: 1501-218 file TSRM/TSRM.lo contains an incorrect file suffix cc: 1501-218 file TSRM/tsrm_strtok_r.lo contains an incorrect file suffix cc: 1501-218 file TS
#28154 [NEW]: Simple Xml output only utf-8
From: jay at kuantic dot com
Operating system: linux fedora core 1
PHP version: 5.0.0RC1
PHP Bug Type: *XML functions
Bug description: Simple Xml output only utf-8
Description:
Simple Xml seems to output only utf-8. No matter how specified in
encoding='iso-8859-1' and not simple function to change encodage.
Reproduce code:
---
$xmlstr = <<
Gestion des Objets
Gestion des Géolocalisation
Autres questions...
XML;
$xml = simplexml_load_string($xmlstr);
foreach ($xml->section->title as $title) {
echo $title, '';
}
?>
Expected result:
Gestion des Objets
Gestion des Géolocalisation
Autres questions...
Actual result:
--
Gestion des Objets
Gestion des Géolocalisation
Autres questions...
--
Edit bug report at http://bugs.php.net/?id=28154&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28154&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28154&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28154&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28154&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28154&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28154&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28154&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28154&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28154&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28154&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28154&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28154&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28154&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28154&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28154&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28154&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28154&r=float
#7639 [Com]: $REMOTE_HOST
ID: 7639 Comment by: jay at jvstudios dot com Reported By: niels at nielsonline dot com Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.3pl1 New Comment: Hi, A work around - $rhost = @gethostbyaddr($REMOTE_ADDR); Laters Previous Comments: [2000-11-05 12:36:23] [EMAIL PROTECTED] closed [2000-11-04 20:18:57] [EMAIL PROTECTED] REMOTE_HOST is only available if your web server is configured to do dns lookups on each request. By default dns lookups are not turned on in Apache, so I would guess that this is your problem and that it has nothing to do with PHP. [2000-11-04 17:28:37] niels at nielsonline dot com Hi, $REMOTE_HOST doesn't work in php4.0.3pl1. Maybie this bug has been submitted already, but i coul'd not find a list of submitted bugs. Bye ;) Niels - nielsonline.com -- Edit this bug report at http://bugs.php.net/?id=7639&edit=1
#27291 [Asn->Csd]: get_browser matches browscap.ini patterns incorrectly
ID: 27291 Updated by: [EMAIL PROTECTED] Reported By: php-bug-NOSPAM-2004 at ryandesign dot com -Status: Assigned +Status: Closed Bug Type: *General Issues Operating System: * PHP Version: 4CVS, 5CVS (2004-02-20) Assigned To: jay 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. This fix should provide the same results as browscap.dll now. J Previous Comments: [2004-02-24 18:43:35] [EMAIL PROTECTED] Forgot to assign this to myself. Pretty close to having a decent fix based on what I'm seeing in browscap.dll. J [2004-02-23 21:14:19] php_bug_27291 at garykeith dot com In looking at browscap.ini with all Gecko-based browsers now using Gecko/* instead of Gecko/ I can find no reason why Netscape 7.x should have a problem with my definitions. I mean, what's wrong with the following browscap.ini definition? Mozilla/5.0 (Windows; ?; Windows NT 5.2; *) Gecko/* Netscape7/7.2* By any reasonable standard it should recognize this user agent as Netscape 7.2. In my tests using browscap.dll that's exactly what it did. Have I found yet another bug? Or did I completely miss what you were trying to tell me? Thanks for the tip about Camino. I don't see it very often in my logs. I've added the plus version to my database but haven't published it yet. I will bundle up all the files you requested and make them available on one of my servers. I'll e-mail you privately once that's done as I do not want to publicize the URL, LOL. [2004-02-23 17:25:44] php-bug-NOSPAM-2004 at ryandesign dot com Yes, I'm sorry, I meant to mention that changing to match Gecko/* instead of Gecko/ would seem to adversely affect Netscape 7.x, whose UA string starts the same way, but ends, after the Gecko/xxx part, with Netscape/xxx. Other things you should look out for in your file: I think you may be missing a pattern for the Camino browser version 0.7+. That's what you get if you use the latest nightly builds, which is effortlessly achieved by using the program CaminoKnight, and since 0.7 proper is so ancient now, most Camino users probably are running the 0.7+ builds. The UA string ends with the + sign but seems otherwise the same to what you have in the 2/15/04 file. Confirmed that the new browscap.ini from 2/15/04 causes a parse error at Apache startup. Filed http:// bugs.php.net/27372 Sorry about my shorthand... by .tgz I just meant a compressed file. A Zip file would be fine too. If you could bundle up your huge UA list, and possibly also your script to feed these to browscap.dll, and put them on a web or ftp server like Jay did or just email them to me, that'd be great. [2004-02-23 16:46:16] php_bug_27291 at garykeith dot com Sorry I forgot to address your proposal. You do need IIS to use browscap.dll. The problem is you cannot pass a user agent to it directly like you can with PHP. I have a script (in ASP/VBScript obviously, but probably easily converted to PHP) that lets you pass a specific user agent to browscap.dll and get the resulting browser in return. [2004-02-23 16:39:22] php_bug_27291 at garykeith dot com Tell me what a .tgz file is and if I can do it I will. I'm working two new bugs that I hope someone will post bug reports about. The first deals with the exclamation point that's part of the new Yahoo! Slurp crawler. I'm not sure what PHP is doing since I don't speak PHP but I'm told it's throwing a parsing error. I've also had some complaints from people saying user agents aren't being recognized since I switched from using Gecko/ to Gecko/* as we discussed earlier. 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/27291 -- Edit this bug report at http://bugs.php.net/?id=27291&edit=1
#27506 [Dup]: browscap.ini parsing again
ID: 27506 Updated by: [EMAIL PROTECTED] Reported By: spaze at exploited dot cz Status: Duplicate Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.4 New Comment: Oops, you're right. Apparently I need more practice with ye olde cut 'n' paste feature. The real duplicate report is at #27372. J Previous Comments: [2004-03-05 15:36:47] spaze at exploited dot cz you amuse me, J - this is bug #27506 - so we have a cyclic duplication here :) but anyway, thanks for the comment. [2004-03-05 15:26:44] [EMAIL PROTECTED] Duplicate of #27506. It will probably take a new ini parser to fix this. We're looking at options now. J [2004-03-05 12:37:59] spaze at exploited dot cz Description: this is just to remind http://bugs.php.net/19649, which is now closed. but the last mentioned problem is serious enough to repost it here again.. copy/paste from the original post: -- snip from browscap.ini -- [Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)] parent=Yahoo browser=Yahoo! Slurp AK=False SK=False -- end snip -- The "!" in the browser key is causing this problem on my system. The "!" in the section name is ok. When I remove the bang from the browser key, the browser.ini is able to load properly. -- Edit this bug report at http://bugs.php.net/?id=27506&edit=1
#27506 [Opn->Dup]: browscap.ini parsing again
ID: 27506 Updated by: [EMAIL PROTECTED] Reported By: spaze at exploited dot cz -Status: Open +Status: Duplicate Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.4 New Comment: Duplicate of #27506. It will probably take a new ini parser to fix this. We're looking at options now. J Previous Comments: [2004-03-05 12:37:59] spaze at exploited dot cz Description: this is just to remind http://bugs.php.net/19649, which is now closed. but the last mentioned problem is serious enough to repost it here again.. copy/paste from the original post: -- snip from browscap.ini -- [Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)] parent=Yahoo browser=Yahoo! Slurp AK=False SK=False -- end snip -- The "!" in the browser key is causing this problem on my system. The "!" in the section name is ok. When I remove the bang from the browser key, the browser.ini is able to load properly. -- Edit this bug report at http://bugs.php.net/?id=27506&edit=1
#27500 [Opn->Fbk]: get_browser
ID: 27500 Updated by: [EMAIL PROTECTED] Reported By: cvachon at bluenodes-technologies dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: XP PHP Version: 4.3.5RC3 New Comment: Could you check to make sure you're not experiencing the same problem as has been reported in bug #27372? http://bugs.php.net/bug.php?id=27372 J Previous Comments: [2004-03-04 18:23:54] cvachon at bluenodes-technologies dot com Description: Hi! I downloaded the latest "browsecap.ini" (2004-02-29 23:03:10 GMT ) file yesterday and it generates a bug within PHP function "get_browser". This function is supposed to return an Object but with this file version, it returns nothing. I have PHP 4.3.5RC3 under XP. And I even tried downgrading to my last PHP version (4.3.4RC3) and the result is the same... My conclusion is based on the fact that I downgraded to an ancient version of the file "browsecap.ini" (2003-09-21 22:04:18 GMT) and it's working with this one... Thanks! Reproduce code: --- $browser = get_browser($_SERVER["HTTP_USER_AGENT"]); Expected result: Object Actual result: -- //* $browser is null and does not have any properties set. -- Edit this bug report at http://bugs.php.net/?id=27500&edit=1
#27291 [Opn]: get_browser matches browscap.ini patterns incorrectly
ID: 27291 Updated by: [EMAIL PROTECTED] Reported By: php-bug-NOSPAM-2004 at ryandesign dot com Status: Open Bug Type: *General Issues Operating System: * PHP Version: 4CVS, 5CVS (2004-02-20) -Assigned To: +Assigned To: jay New Comment: Forgot to assign this to myself. Pretty close to having a decent fix based on what I'm seeing in browscap.dll. J Previous Comments: [2004-02-23 21:14:19] php_bug_27291 at garykeith dot com In looking at browscap.ini with all Gecko-based browsers now using Gecko/* instead of Gecko/ I can find no reason why Netscape 7.x should have a problem with my definitions. I mean, what's wrong with the following browscap.ini definition? Mozilla/5.0 (Windows; ?; Windows NT 5.2; *) Gecko/* Netscape7/7.2* By any reasonable standard it should recognize this user agent as Netscape 7.2. In my tests using browscap.dll that's exactly what it did. Have I found yet another bug? Or did I completely miss what you were trying to tell me? Thanks for the tip about Camino. I don't see it very often in my logs. I've added the plus version to my database but haven't published it yet. I will bundle up all the files you requested and make them available on one of my servers. I'll e-mail you privately once that's done as I do not want to publicize the URL, LOL. [2004-02-23 17:25:44] php-bug-NOSPAM-2004 at ryandesign dot com Yes, I'm sorry, I meant to mention that changing to match Gecko/* instead of Gecko/ would seem to adversely affect Netscape 7.x, whose UA string starts the same way, but ends, after the Gecko/xxx part, with Netscape/xxx. Other things you should look out for in your file: I think you may be missing a pattern for the Camino browser version 0.7+. That's what you get if you use the latest nightly builds, which is effortlessly achieved by using the program CaminoKnight, and since 0.7 proper is so ancient now, most Camino users probably are running the 0.7+ builds. The UA string ends with the + sign but seems otherwise the same to what you have in the 2/15/04 file. Confirmed that the new browscap.ini from 2/15/04 causes a parse error at Apache startup. Filed http:// bugs.php.net/27372 Sorry about my shorthand... by .tgz I just meant a compressed file. A Zip file would be fine too. If you could bundle up your huge UA list, and possibly also your script to feed these to browscap.dll, and put them on a web or ftp server like Jay did or just email them to me, that'd be great. [2004-02-23 16:46:16] php_bug_27291 at garykeith dot com Sorry I forgot to address your proposal. You do need IIS to use browscap.dll. The problem is you cannot pass a user agent to it directly like you can with PHP. I have a script (in ASP/VBScript obviously, but probably easily converted to PHP) that lets you pass a specific user agent to browscap.dll and get the resulting browser in return. [2004-02-23 16:39:22] php_bug_27291 at garykeith dot com Tell me what a .tgz file is and if I can do it I will. I'm working two new bugs that I hope someone will post bug reports about. The first deals with the exclamation point that's part of the new Yahoo! Slurp crawler. I'm not sure what PHP is doing since I don't speak PHP but I'm told it's throwing a parsing error. I've also had some complaints from people saying user agents aren't being recognized since I switched from using Gecko/ to Gecko/* as we discussed earlier. [2004-02-23 12:58:19] php-bug-NOSPAM-2004 at ryandesign dot com Sounds like what we need is a script that takes the user agents logged by a popular web site, runs them through browscap.dll and PHP's get_browser(), compares the results, and informs a PHP programmer about any differences, so that get_browser() can be kept in line. I hate to volunteer for such a task, as I'm not a member of the PHP team, but perhaps, once my patch or one like it is applied, I could try it out for awhile to see what quantity of diffs is generated. I'm not sure, however, how I would use browscap.dll. What kind of server would need to be used, and what programming language? I have a feeling you're going to say Microsoft IIS and Visual Basic or ASP or some such, none of which I've ever worked with. (I wouldn't know where to begin.) But if a system could be developed whereby one popular web server gathers a day's UA's, and then pass
#27291 [Opn]: get_browser matches browscap.ini patterns incorrectly
ID: 27291 Updated by: [EMAIL PROTECTED] Reported By: php-bug-NOSPAM-2004 at ryandesign dot com Status: Open Bug Type: *General Issues Operating System: Mac OS X; FreeBSD; RedHat Linux PHP Version: 4.3.5RC3 New Comment: I had done some work on the get_browser() function a while back, and I believe those were the last major changes to occur to that function. The function seemed to have been abandoned for quite some time before those changes. For the most part, based on the testing I did, the results seemed quite favourable, i.e. more information was now being returned by the function, such as operating systems and such that were previously missing from get_browser()'s output. Obviously there is still some room for improvement, though. I tried the original poster's patch using Gary's most up-to-date browscap.ini file and had some mixed results. I tested all of the unique user agent strings we had in our apache logs at work (1914 strings) and the results were sometimes better, sometimes worse, but overall they were pretty much the same. Here's a few things I noticed: - Netscape 7.x on Linux is better after the changes. (It was being reported as Mozilla 1.4 previously.) - Serveral versions of Mozilla on linux come up as Default Browser after the changes, as opposed to the correct information before the changes. - Something identified as a "Spoofed IE" is coming up correct before the changes, but comes up as Default Browser after the changes. - Epiphany 1.0 gets Default Browser after the changes, but comes up with "Mozilla 1.4" before the changes. - Some versions of Safari are being reported as Default Browser after the changes, while before the changes they seem to be coming up properly. (This includes the example in the original poster's example, which came up as Safari 1.1 on my system.) - Some versions of Galeon are being reported better after the changes. - Some user agents that were reported as being Website Strippers before are now being reported as Default Browser. You can find the results of the tests, the UA strings I used and the script to generate them here: http://216.94.11.234/browsers.tar.gz That's with an up-to-date PHP_4_3 checkout and the latest browscap.ini. To Gary: I'll take any suggestions on how to improve get_browser(). Is there any similar implementation that provides better results that I can get ahold of? I see things for IIS, Java, etc. on your site, but is any of them better than the rest that I should look at? J Previous Comments: [2004-02-19 07:12:52] php-bug-NOSPAM-2004 at ryandesign dot com Sorry, Gary; my bad. When using the Feb 15, 2004 browscap.ini, I had just looked at the browser match long enough to see that it found Safari, and did not look close enough to realize that the rule specifically matched the Safari v100 series. Due to one oddity in PHP's parsing code (a fix for which I provide through the commenting out of three lines, as seen in my diff), it ends up recognizing any Safari where the version number starts with 1, regardless of how many chars follow, which is why it recognized the fictitious version v1999 in my test case. I have now found the place where the PHP CVS snapshots are kept (http://snaps.php.net), and have downloaded and compiled the stable 4.3.x snapshot from Feb 19, 2004 10:30 GMT. Its behavior in relation to this bug remains unchanged when compared with the 4.3.4 and 4.3.5RC3 releases; it's still broken. I'd like to suggest that the PHP team reconsider evaluating and applying the diff I supplied in my original report. [2004-02-18 16:23:42] php_bug_27291 at garykeith dot com Respectfully, my latest browscap.ini does not detect all arbitrary versions of Safari. I'm not sure how you arrived at that conclusion. I do know that I receive e-mails nearly every day about this issue so there is obviously a problem somewhere. I don't know who is working on the code for get_browser() these days but I wish they would contact me so we could come to some sort of understanding about how to properly parse my file the way browscap.dll does. I am growing very weary of my files and efforts taking the blame for the non-stop stream of bugs that emanate from get_browser(). Thanks, ~gary. [2004-02-17 16:12:58] [EMAIL PROTECTED] Using latest stable CVS snapshot does match with "Default Browser".. [2004-02-17 14:01:22] php-bug-NOSPAM-2004 at ryandesign dot com Description: PHP's get_browser() function does not correctly us
#27004 [Opn->Bgs]: DenialOfService-Risk with wrong Usage
ID: 27004
Updated by: [EMAIL PROTECTED]
Reported By: kmb at deam dot org
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: Debian-Linux (Woody), MacOS X.3
PHP Version: Irrelevant
New Comment:
There are lots of ways that you can DOS yourself, and
using file() recursively in a script on itself is one of
them. It can't really be fixed, though, much like going
through an infinitely recursive function call or infintely
forking until memory is exhausted. There are several other
bug reports dealing with this sort of thing that explain
things further. (Search for 'recursive', for instance.)
Basically, we need to trust that users aren't going to DOS
themselves.
J
Previous Comments:
[2004-01-22 06:07:02] kmb at deam dot org
Description:
Calling somith within a PHP-Script recursively can result into one of
these results:
1. general PHP-error and stop
2. max_execution_time and stop
3. max_input_time and stop
4. memory_limit and stop
If you use the file()-function to call yourself, one of the upper
limits will occure, but it won't stop with that.
You can overload the Apache with a lot of reqeusts so that there will
be no more response. Your initial request will timeout, but the Apache
won't come back if you do not restart it.
The trouble is, that there is currently no way to suppress this
behaviour or at least leave some resources open
Reproduce code:
---
$in = file("http://local.dom/myself.php";, "r");
Expected result:
some sort of "filter" to slow down the request of resource-usage.
Actual result:
--
It uses up all Apache-processes up to MaxClient-Limit and ends in a
total DOS of the Apache.
--
Edit this bug report at http://bugs.php.net/?id=27004&edit=1
#26768 [Opn->Fbk]: substr_replace don't replace
ID: 26768 Updated by: [EMAIL PROTECTED] Reported By: pb at tdcspace dot dk -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: NT PHP Version: Irrelevant New Comment: This is a pretty old version of PHP. Can you try using the latest version, PHP 4.3.4? J Previous Comments: [2004-01-02 11:49:38] pb at tdcspace dot dk Description: PHP 4.3.1 running on a web-host with NT! Note: YES - i have tried to search for this bug ! A php-script to replace (change) varnames in other php-scripts. Quite simple - but it only works on smaller files i.e. substr_replace apparently does not work on a string of about 10k. Bug is: nothing is replaced by substr_replace but returned unchanged ! short code ex: $x = file_get_contents($fn);// read source into string $x = strtolower($x); // make lowercase for search $p = strpos($x, $oldvarname); // find varname $x = substr_replace($x, $newvarname, $p, strlen($oldname)); ...save the string to a file with changed varnames as said - it works on smaller files/strings (2k) but not if the file/string is - say - 10k. -- Edit this bug report at http://bugs.php.net/?id=26768&edit=1
#26419 [Opn->Bgs]: ob_gzhandler and pdf
ID: 26419
Updated by: [EMAIL PROTECTED]
Reported By: giuseppe dot costagliola at sanpaolowm dot com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: OS400
PHP Version: 4.3.3
New Comment:
Since you fixed the problem (which is most likely an IE
bug), bogusing...
J
Previous Comments:
[2003-11-26 04:18:09] giuseppe dot costagliola at sanpaolowm dot com
We tried to set
zlib.output_compression = on
in php.ini and disable with
ini_set("zlib.output_compression","off")
right before sending pdf and this way seems to work.
[2003-11-26 03:35:05] giuseppe dot costagliola at sanpaolowm dot com
Description:
We configured "output_handler = ob_gzhandler" and it works fine for any
text/html output.
However when our php page creates a pdf to be seen online, the IE
prompts for download (while on Netscape it's displayed correctly).
--
Edit this bug report at http://bugs.php.net/?id=26419&edit=1
#26325 [Opn]: At least a notice when accessing private members in a derived class?
ID: 26325 Updated by: [EMAIL PROTECTED] Reported By: drm at melp dot nl Status: Open -Bug Type: Feature/Change Request +Bug Type: Zend Engine 2 problem Operating System: Windows XP PHP Version: 5.0.0b2 (beta2) New Comment: Take your original example and edit it so it works in PHP 4. It runs in both 4 and 5 without a notice. Based on your original example code, that isn't "just plain bs." Upon further inspection based on your second example, there is definitely something weird going on here. This is most likely related to #26182. J I'm not positive, but I think this may have something to do with #26182. J Previous Comments: [2003-11-22 18:57:46] drm at melp dot nl You are right, i hadn't researched the problem that well, since i assumed php5 would treat properties the php4-style the same way as php4 itself. But you are right; the code sample above when ran in php5 doesn't give a notice, though php4 does. [2003-11-22 10:26:03] [EMAIL PROTECTED] Actually, the main issue here is that PHP doesn't give a notice at all if you access an undefined property, whether it is a private property in a base class or not. [2003-11-22 09:05:03] drm at melp dot nl Excuse me, but you are *totally* missing my point here. You are telling me things i had already pointed out in the first post. I'll reduce my feature request to one simple line: Can *at least* a "notice" be triggered when a private member variable does not exist but is accessed? And by accessed i do NOT mean assigned! You're saying it behaves the same way php4 does, but that's just plain bs. See the following code in PHP4: member; } } $t = new Test (); echo $t->getMember (); ?> This would yield the following notice: Notice: Undefined property: member in test.php on line 5 All i'm asking is that some notice of the SAME sort can be implemented in php5 when trying to access parent private members. [2003-11-20 11:46:55] [EMAIL PROTECTED] There are two issues here. First, PHP 5 is just acting like PHP 4 did -- you can initialize a member of an object without explicitly declaring it in the class definition and PHP won't complain. Second, Test::$member and DeriveTest::$member aren't the same things. Test::$member being private, it's only accessible and visible from within Test. DeriveTest has no idea it exists, so it creates its own public member called $member. If you do a print_r($o) at the end of your script, you'll see that there are two members called $member, one of which is private and the other public. So yes, this is intended behaviour. One of the main ideas of private members is that they aren't even visible from derived classes. If you try to access a private member from a parent class, the derived class won't see it and will instead try using its own member, and if that doesn't exist it will implicitly create it. J [2003-11-20 04:45:48] drm at melp dot nl Here's a more explanatory piece of code: http://gerard.yoursite.nl/php.net/private-members.phps 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/26325 -- Edit this bug report at http://bugs.php.net/?id=26325&edit=1
#26342 [Opn->Bgs]: Function does not return any values at all.
ID: 26342
Updated by: [EMAIL PROTECTED]
Reported By: ccetanr at nus dot edu dot sg
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: WIN XP
PHP Version: 4.3.4
New Comment:
That's absolutely correct. Do a var_dump() instead of a
print_r() to see the boolean return value.
J
Previous Comments:
[2003-11-21 17:36:33] roleli at hotmail dot com
Not a bug.
the fuction returns TRUE or FALSE.
you can test e.g
if (checkdate(11,32,2003))
{
echo "Date ok";
}
else
{
echo "Date not ok";
}
Look at the documentation at
http://us4.php.net/manual/en/function.checkdate.php
Roland
[2003-11-21 02:07:31] ccetanr at nus dot edu dot sg
Description:
When return the value from the function, no value is returned.
Reproduce code:
---
Expected result:
Nothing returns?
--
Edit this bug report at http://bugs.php.net/?id=26342&edit=1
#26349 [Opn->Bgs]: is_numeric() returns false for strings with more than 308 characters
ID: 26349 Updated by: [EMAIL PROTECTED] Reported By: kouber at saparev dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Win 2000 NT PHP Version: 4.3.4 New Comment: Please see the note on the maximum value of floats at http://www.php.net/manual/en/language.types.float.php When is_numeric() checks a string, it tries to convert the string to a long, then a double. Anything greater than approximately 1.8e308 is too large for a double, so it becomes infinity. Try a var_dump() on the value and you'll see what I mean. (This behaviour is platform-dependent, of course.) J Previous Comments: [2003-11-21 09:22:31] kouber at saparev dot com Description: is_numeric() always returns false for strings with more than 308 characters, even if all of them are digits. 308 = 255 + 63 = 2^8-1 + 2^6-1 Reproduce code: --- Expected result: string(309) "6" bool(true) Actual result: -- string(309) "6" bool(false) -- Edit this bug report at http://bugs.php.net/?id=26349&edit=1
#26331 [Csd->Bgs]: Wrong documents loaded in frames
ID: 26331 Updated by: [EMAIL PROTECTED] Reported By: john dot gray at synerge dot com dot au -Status: Closed +Status: Bogus Bug Type: Output Control Operating System: Mandrake 8.1 PHP Version: 4.3.2 New Comment: Just bogusing this because this wasn't a bug in the first place... J Previous Comments: [2003-11-20 10:40:55] john dot gray at synerge dot com dot au Sorry - turns out the issue was mod_rewrite(with rewrite map) -> mod_perl -> php. Took mod_perl out and went direct and it works beautifully! Should have known better than to think Zend would have a prob like that :-) [2003-11-20 09:47:57] john dot gray at synerge dot com dot au Description: I have a problem with a site that uses frames heavily, and I am using php simply to pass-thru html documents and images so I can do my own (very complex) security - intermittently, the wrong document is sent to the wrong frame - with images, it is particularly bad with the wrong binary image data loading in the wrong place on the page. Could this be something to do with global variables? are they global across threads -- Edit this bug report at http://bugs.php.net/?id=26331&edit=1
#26325 [Opn->Bgs]: At least a notice when accessing private members in a derived class?
ID: 26325
Updated by: [EMAIL PROTECTED]
Reported By: drm at melp dot nl
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.0.0b2 (beta2)
New Comment:
There are two issues here.
First, PHP 5 is just acting like PHP 4 did -- you can
initialize a member of an object without explicitly
declaring it in the class definition and PHP won't
complain.
Second, Test::$member and DeriveTest::$member aren't the
same things. Test::$member being private, it's only
accessible and visible from within Test. DeriveTest has no
idea it exists, so it creates its own public member called
$member. If you do a print_r($o) at the end of your
script, you'll see that there are two members called
$member, one of which is private and the other public.
So yes, this is intended behaviour. One of the main ideas
of private members is that they aren't even visible from
derived classes. If you try to access a private member
from a parent class, the derived class won't see it and
will instead try using its own member, and if that doesn't
exist it will implicitly create it.
J
Previous Comments:
[2003-11-20 04:45:48] drm at melp dot nl
Here's a more explanatory piece of code:
http://gerard.yoursite.nl/php.net/private-members.phps
[2003-11-19 17:49:24] drm at melp dot nl
Description:
Hi :)
I read in the new features list of Zend Engine 2 that access modifiers
like private/protected are introduced, but something really weird comes
in mind when reading carefully.
Private members are returned _empty_ wheing tried to be accessed from
derived classes. "Intended behaviour", is said. OK, i can live with
that. But even when i turned on notices with error_reporting, nothing
is noticed?
The case grows when looking at the following code sample. This could
produce very weird bugs when writing PHP code (i hope you can see that
;)), so I would like to convince you all to at least implement a Notice
when trying to access (non-defined) private (parent) members?
It would do the coders not using E_ALL no harm :) Please consider this
:)
Reproduce code:
---
error_reporting ( E_ALL );
class Test {
private $member;
function __construct () { $this->member = "Test constructor";
}
function __toString (){ return "Member contains:
{$this->member}"; }
function getMember () { return $this->member; }
function setMember ( $m ) { $this->member = $m; }
}
class DeriveTest extends Test {
function __construct () { parent::__construct (); }
function __toString (){ return "Member contains:
{$this->member}, though getMember() says: " . $this->getMember() ."?";
}
function setMember ( $m ) { $this->member = $m; }
}
$o = new DeriveTest ();
echo $o, '';
$o->setMember ( "a" );
echo $o, '';
Expected result:
The expected result would be for me:
Notice: undefined member ``DeriveTest::$member'' in ...\test.php on
line 12
Member contains: , though getMember() says: Test constructor?
Member contains: a, though getMember() says: Test constructor?
or something of the sort
Actual result:
--
The actual result is:
Member contains: , though getMember() says: Test constructor?
Member contains: a, though getMember() says: Test constructor?
--
Edit this bug report at http://bugs.php.net/?id=26325&edit=1
#25916 [Fbk]: get_browser() -> PHP Fatal error: Nesting level too deep - recursive dependency?
ID: 25916
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Solaris 9
PHP Version: 4.3.4RC1
New Comment:
The browscap extension definitely leaks, but as far as I
know, it's only during module startup/shutdown, and it's
been like that since forever. I've never seen it blow up
like this, but I can try to reproduce on Solaris 8 with
iPlanet. Is there anything special that needs to be done
besides hammering the test script with requests?
I've been meaning to take another look at the browscap
stuff, that extension has kind of been disowned...
J
Previous Comments:
[2003-11-19 03:29:37] [EMAIL PROTECTED]
Yes I would like to do that. Could be a memory leak. I followed the
discussion. But these fixes are for PHP5 only!
[2003-11-17 18:33:08] [EMAIL PROTECTED]
mr. Richards posted some patch(es) to internals@ to fix some ZTS
related issues. Maybe you should try those?
[2003-10-20 04:30:58] [EMAIL PROTECTED]
Addendum: It is not a problem with wrong extension dir in php.ini
(because all extensions are linked static) like in other bugs.
The configuration phpinfo() can be found at:
http://134.1.2.11/test.php
[2003-10-20 03:39:01] [EMAIL PROTECTED]
Description:
The following error occurs sometimes on the ext/standard function
get_browser():
[20/Oct/2003:08:54:59] info (13034): for host
p5084725C.dip.t-dialin.net trying to GET /index.php, php4_execute
reports: PHP Fatal error: Nesting level too deep - recursive
dependency? in /pangaea/htdocs/www.pangaea.de/index.php on line 28
Line 28 contains the call to get_browser(). All other PHP functions do
not fail. In other scripts which use get_browser() the error also
occurs.
The problem is: You cannot reproduce it, because it happens only on
heavy server load and when it happens the first time it does not go
away until server restart.
PHP runs on SunONE with NSAPI, so compiled with ZTS.
I would debug the code and fix the error; but my problem is that I do
not know WHERE in get_browser the error occurs.
Uwe
Reproduce code:
---
http://www.google.de/search?sourceid=navclient&hl=de&q=%22age%2C+error%22+pangaea
//
http://www.google.de/search?q=%22age,+error%22+pangaea&hl=de&lr=&ie=UTF-8&filter=0
if (isset($_GET['query'])) {
$query=$_GET['query'];
} else {
if (isset($_SERVER['HTTP_REFERER']) &&
preg_match('/^http:\/\/.*?google\..*?\/search\?(.*?)$/i',
$_SERVER['HTTP_REFERER'], $matches)) {
$a = split ('&', $matches[1]);
for ($i=0; $icrawler) && isset($_SERVER['PATH_INFO'])) {
if (isset($query)) {
header("Location:
http://".$_SERVER['HTTP_HOST']."/?query=".urlencode($query));
} else {
header("Location: http://".$_SERVER['HTTP_HOST']."/");
}
exit();
}
// if a crawler like google is visiting: prepare keyword list to
display and extract page number
if ($browser->crawler) {
$page=0;
if (isset($_SERVER['PATH_INFO'])) {
if (preg_match('/^\/(.*?)\.html$/', $_SERVER['PATH_INFO'],
$matches)) {
$page=$matches[1];
} else {
header("HTTP/1.0 404 Not Found");
exit();
}
}
$lines=file("../globals/googlelist.txt");
if ($page*1000>=count($lines)) {
header("HTTP/1.0 404 Not Found");
exit();
}
}
?>
...
--
Edit this bug report at http://bugs.php.net/?id=25916&edit=1
#26299 [Opn->Bgs]: Inheritance problem: an object can have two same-named private variables
ID: 26299 Updated by: [EMAIL PROTECTED] Reported By: forseti at oak dot rpg dot pl -Status: Open +Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Windows 98 SE PHP Version: 5.0.0b2 (beta2) New Comment: This is expected. When a member is private, it can only be seen by the class it is a member of. Class B has no idea class A also has a member called $a and goes ahead and creates one. It's just a matter of visibility. J Previous Comments: [2003-11-18 10:05:05] forseti at oak dot rpg dot pl Description: When extending a class, private member variables from parent class are retained even if child class defines same-named variable. Reproduce code: --- ';print_r(new B);echo ''; ?> Expected result: b Object ( [a:private] => From class B ) Actual result: -- b Object ( [a:private] => From class B [a:private] => From class A ) -- Edit this bug report at http://bugs.php.net/?id=26299&edit=1
#26130 [NoF->Opn]: IBM DB2 Unique Key Problem
ID: 26130 User updated by: jay at nicwr dot mah dot nic dot in Reported By: jay at nicwr dot mah dot nic dot in -Status: No Feedback +Status: Open Bug Type: ODBC related Operating System: Linux 8.0 PHP Version: 4.3.2 New Comment: Still the problem persist in php 4.3.4 Previous Comments: [2003-11-17 18:18:38] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-11-05 00:51:58] [EMAIL PROTECTED] Please upgrade first to PHP 4.3.4. And then try this script and paste the output here: [2003-11-05 00:43:17] jay at nicwr dot mah dot nic dot in Description: I have IBM DB2 V 7.2 EE Fix Pack 7 My Php is enabled with ibm-db2 support I have a table test (c1 int not null,c2 int,c3 int) I have a unique key on table test as (c1) with include options for (c2,C3) If I have a sample data 1,null,null 2,1,null, 3,null,1 4,1,2 If I access the data thru my php script I do not get desirable result. Reproduce code: --- "; } ?> Expected result: Expected Result is as follows - Record:1---End Record Record:2-1--End Record Record:3--1-End Record Record:4-1-2-End Record Actual result: -- Actual Results Appear as follows Record : ---End Record Record : ---End Record Record : ---End Record Record : 4-1-2-End Record -- Edit this bug report at http://bugs.php.net/?id=26130&edit=1
#26273 [Opn->Bgs]: conditional concatenator
ID: 26273
Updated by: [EMAIL PROTECTED]
Reported By: tagg_maiwald at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows 98
PHP Version: 4.3.4
New Comment:
How is this any different from the already-implemented
ternary operator?
$sz_string .= ($bool_test) ? 'bar' : 'baz';
J
Previous Comments:
[2003-11-16 10:04:14] tagg_maiwald at yahoo dot com
Description:
A conditional concatenator would evaluate a boolean test, then
concatenate a value onto the left operand. This operator would simplify
scripts by eliminating a kludge. The motive behind this request is to
readily construct SQL queries via PHP which can be easily reread and
understood with minimal confusion by a follow-on person maintaining the
script(s).
Reproduce code:
---
// kludge
$sz_string = 'foo';
if ($bool_test) { $sz_string .= 'bar'; }
else { $sz_string .= 'baz'; }
echo $sz_string
// conditional concatenator
$sz_string = 'foo';
$sz_string .? ($bool_test) 'bar' : 'baz';
echo $sz_string
Expected result:
foobar
Actual result:
--
foobar
--
Edit this bug report at http://bugs.php.net/?id=26273&edit=1
#26283 [Opn->Bgs]: 3des keys length
ID: 26283
Updated by: [EMAIL PROTECTED]
Reported By: stjeffy at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: mcrypt related
Operating System: windows 2000,linux
PHP Version: 4.3.2
New Comment:
The key is expected to be in binary, not hex. Try using
pack() to convert the string from hex to bin, i.e.
$strKey = pack('H48', "3FD3...");
J
Previous Comments:
[2003-11-17 03:14:11] stjeffy at hotmail dot com
Description:
I work with mcrypt to encrypt the string by Triple DES. But I meet with
the key length problem.
I use a 24BYTE key, the key
is(HEX)3FD3A3DABD10B0FF6EAFB5A0103D386EAF6E3F8CAED6CD93
After executing a instance,
the system reports the following error:
mcrypt_generic_init(): Key size too large; supplied length: 48, max: 24
in
and cut off the half of the original key to calculate the 3des result.
And I find there exists the same problem in php.net' online help-- the
2nd example provided in http://www.php.net/manual/en/ref.mcrypt.php.
Reproduce code:
---
$strSource = "http://www.php.net/test.php";;
$strKey = "3FD3A3DABD10B0FF6EAFB5A0103D386EAF6E3F8CAED6CD93";
$td = mcrypt_module_open (MCRYPT_3DES, '', 'ecb', '');
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);
mcrypt_generic_init ($td, $strKey, $iv);
$strCode = mcrypt_generic ($td, $strSource);
mcrypt_generic_end ($td);
echo base64_encode($strCode);
Expected result:
w6e8c9Tp0/PejfYYvgJJu3cHUXYg29CQAthGmi480Ng=
Actual result:
--
LMke4PuG37H9vP5gvRoVwQkX0hZrtfE9NB/az+lSLcc=
--
Edit this bug report at http://bugs.php.net/?id=26283&edit=1
#26232 [Opn->Bgs]: in_array produces true when bool true is in haystack
ID: 26232
Updated by: [EMAIL PROTECTED]
Reported By: me at my dot house
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.2, 5b2
New Comment:
That's what Ilia was getting at. If the third parameter to
in_array() is true, types are also checked a-la ===.
As per your example...
[EMAIL PROTECTED] jay $ php -r
'var_dump(in_array("x",array(1,2,3,true)));'
bool(true)
[EMAIL PROTECTED] jay $ php -r
'var_dump(in_array("x",array(1,2,3,true), true));'
bool(false)
J
Previous Comments:
[2003-11-14 02:42:55] [EMAIL PROTECTED]
Yes it is correct BUT in this case i suggest we add an option to the
function to switch to === checks.
[2003-11-13 19:34:21] [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
This is to be expected. Jay's explanation clearly identifies the fault
in the PHP script. In this situation you should specify the 3rd
parameter to in_array(), which would make comparison strict.
[2003-11-13 10:55:42] [EMAIL PROTECTED]
Isn't this sort of expected? "x" should be converted to a
boolean and compared to true, and obviously true == true.
J
[2003-11-13 03:27:55] [EMAIL PROTECTED]
[EMAIL PROTECTED] /usr/src/php5 $ php -r
'var_dump(in_array("x",array(1,2,3,false)));'
bool(false)
[EMAIL PROTECTED] /usr/src/php5 $ php -r
'var_dump(in_array("x",array(1,2,3,true)));'
bool(true)
[2003-11-12 22:11:00] me at my dot house
Description:
If the haystack contains the boolean true, in_array returns true!!
Check this (PHP 4.2.3-8 debian package) :
Reproduce code:
---
Expected result:
false
Actual result:
--
true
--
Edit this bug report at http://bugs.php.net/?id=26232&edit=1
#26244 [Opn->Bgs]: regular expression order matters when it shouldn't
ID: 26244 Updated by: [EMAIL PROTECTED] Reported By: willn at umich dot edu -Status: Open +Status: Bogus Bug Type: Regexps related Operating System: Solaris 5.8 PHP Version: 4.3.2 New Comment: The '-' character means range when it's between the [ and ]. You need to put it as the first character or the second character between the [^ and ], which is why $b, $c, $d and $e work fine. J Previous Comments: [2003-11-13 14:36:47] willn at umich dot edu Description: Within the "anti-match" square brackets, order shouldn't make a difference, but it does. I'm writing a simple anti-injection attack filter to pull out all the illegal characters, and leave the ones that I want. Unfortunately, I found that with this particular combination, I've been getting this error message: [Thu Nov 13 14:25:41 2003] [error] PHP Warning: Compilation failed: range out of order in character class at offset 4 in /usr/local/projects/vote-dev/public/test.php on line 5 The code below demonstrates the simplest case I could find that would replicate the problem. Swapping the order a little bit makes it work a little better - as you can see that the $a and $f variables have some issues. Reproduce code: --- Expected result: This, is my - "favorite". a:,-"" b:,-"" c:,-"" d:,-"" e:,-"" f:,-"" Actual result: -- This, is my - "favorite". a: b:,-"" c:,-"" d:,-"" e:,-"" f:,"" -- Edit this bug report at http://bugs.php.net/?id=26244&edit=1
#26232 [Ver]: in_array produces true when bool true is in haystack
ID: 26232
Updated by: [EMAIL PROTECTED]
Reported By: me at my dot house
Status: Verified
Bug Type: Arrays related
Operating System: *
PHP Version: 4.3.2, 5b2
New Comment:
Isn't this sort of expected? "x" should be converted to a
boolean and compared to true, and obviously true == true.
J
Previous Comments:
[2003-11-13 03:27:55] [EMAIL PROTECTED]
[EMAIL PROTECTED] /usr/src/php5 $ php -r
'var_dump(in_array("x",array(1,2,3,false)));'
bool(false)
[EMAIL PROTECTED] /usr/src/php5 $ php -r
'var_dump(in_array("x",array(1,2,3,true)));'
bool(true)
[2003-11-12 22:11:00] me at my dot house
Description:
If the haystack contains the boolean true, in_array returns true!!
Check this (PHP 4.2.3-8 debian package) :
Reproduce code:
---
Expected result:
false
Actual result:
--
true
--
Edit this bug report at http://bugs.php.net/?id=26232&edit=1
#26204 [Opn->WFx]: md5 challenge
ID: 26204 Updated by: [EMAIL PROTECTED] Reported By: hagman at hotbrev dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: Is this keyed hashes we're talking about here? HMAC-type stuff? The mhash provides what you're looking for. There's also an example in the manual in the comments for the mhash function for doing keyed MD5 hashes without installing the mhash extension. btw, brute forcing MD5 isn't something that's particularly easy, keyed or otherwise. J Previous Comments: [2003-11-11 10:24:28] hagman at hotbrev dot com Description: An optional parameter for MD5(), for challenge, this makes it much harder to bruteforce MD5 hashes. Crypt only supports (random) one-way hashes? Reproduce code: --- The source on this has a javascript version. http://www.zonline.jamtland.se/login Expected result: more secure hashes. Actual result: -- i dunno -- Edit this bug report at http://bugs.php.net/?id=26204&edit=1
#26130 [NEW]: IBM DB2 Unique Key Problem
From: jay at nicwr dot mah dot nic dot in Operating system: Linux 8.0 PHP version: 4.3.2 PHP Bug Type: ODBC related Bug description: IBM DB2 Unique Key Problem Description: I have IBM DB2 V 7.2 EE Fix Pack 7 My Php is enabled with ibm-db2 support I have a table test (c1 int not null,c2 int,c3 int) I have a unique key on table test as (c1) with include options for (c2,C3) If I have a sample data 1,null,null 2,1,null, 3,null,1 4,1,2 If I access the data thru my php script I do not get desirable result. Reproduce code: --- "; } ?> Expected result: Expected Result is as follows - Record:1---End Record Record:2-1--End Record Record:3--1-End Record Record:4-1-2-End Record Actual result: -- Actual Results Appear as follows Record : ---End Record Record : ---End Record Record : ---End Record Record : 4-1-2-End Record -- Edit bug report at http://bugs.php.net/?id=26130&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26130&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26130&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26130&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26130&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26130&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26130&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26130&r=support Expected behavior: http://bugs.php.net/fix.php?id=26130&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26130&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26130&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26130&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26130&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26130&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26130&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26130&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26130&r=float
#26120 [Opn->Bgs]: ERROR WHEN TRYING TO REMOVE EMAIL ADDRESS
ID: 26120 Updated by: [EMAIL PROTECTED] Reported By: gajarvis at iquest dot net -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: WIN 98 PHP Version: Irrelevant New Comment: This is not a PHP bug, this a bug/feature on that hosts' mailing/spam list. J Previous Comments: [2003-11-04 14:07:24] gajarvis at iquest dot net Description: Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 RECEIVED THIS MESSAGE WHEN TRYING TO REMOVE EMAIL. Please remove [EMAIL PROTECTED] from all mailing lists. Reproduce code: --- Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 Expected result: Email address [EMAIL PROTECTED] will be removed. -- Edit this bug report at http://bugs.php.net/?id=26120&edit=1
#26042 [Fbk->Ver]: Memory usage
ID: 26042 Updated by: [EMAIL PROTECTED] Reported By: vsv3 at alu dot ua dot es -Status: Feedback +Status: Verified Bug Type: mcrypt related Operating System: Linux 2.4.22 Debian Woody PHP Version: 4.3.2 New Comment: Looks like a leak starting in mcrypt_generic_init(). When mcrypt_generic_init() is called from PHP userland, it never gets deinit'd unless you explicitly call mcrypt_generic_deinit(). Perhaps mcrypt_generic_init() should check to see if the td has already been init'd and if so, deinit it first. Haven't looked too closely at the libmcrypt source yet to see the easiest way to do it. This is using libmcrypt 2.5.7 and an up-to-date 4_3. J Previous Comments: [2003-10-30 13:50:21] [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 And if that doesn't help, give the mcrypt version you're using with PHP. [2003-10-30 10:41:23] vsv3 at alu dot ua dot es Description: When I use the functions for encrypt some data, the memory that PHP uses, doesn't get free. It gets more and more memory. Reproduce code: --- No pudimos destruir la variable"; $n = $n + 1; } mcrypt_module_close( $td ); ?> Expected result: A script that execute with a consume of less than 1MB of memory (with a file '/tmp/hola' of 1kB). Actual result: -- An script that consumes more than 100MB, or more. A similar script with other data, have been consumed more than 2000MB. -- Edit this bug report at http://bugs.php.net/?id=26042&edit=1
#25929 [Bgs]: cannot read cookies within included file
ID: 25929
Updated by: [EMAIL PROTECTED]
Reported By: joe at kybert dot com
Status: Bogus
Bug Type: Variables related
Operating System: XP (debug server)
PHP Version: 4.3.2
New Comment:
I assumed from your first post that when you were
including the file through http, you weren't parsing on
the remote server. (I've seen similar set ups before. Not
recommended, though, or necessary in virtually all cases.)
You can't see the cookie in $_COOKIE from the second file
because it's not being requested from the machine you see
the cookie on, but rather the script that does the
include. If you requested the file as source rather than
parsed so that it would be parsed via the first file, it
would probably work.
Your second example of passing arguments to the second
file won't work either because you can't pass arguments to
a script that way. Just make some variables before
including the file, the second file will see them.
J
Previous Comments:
[2003-10-21 16:05:13] joe at kybert dot com
Why not? The remote file is on the same server, and the cookie was set
to be accessable to all files from that domain.
If you dont include it this way, you cannot pass arguments to the
included file, this doesnt work:
include("{$_SERVER['DOCUMENT_ROOT']}/test/file2.php?myparam=hello");
joe
#
[2003-10-21 15:17:06] [EMAIL PROTECTED]
If you include REMOTE file, of course the cookie is not passed to it.
[2003-10-20 19:59:26] joe at kybert dot com
Description:
Cookie is not readable across multiple files.
I have 2 files, file 1 sets a cookie (refresh file after 1st exe so
cookie is sent)
it then includes file 2, which reads and displays the cookie.
Both files are in the same folder on the server, which is
/test/
.
File 2 fails to read the cookie!
Reproduce code:
---
file1.php contains:
http://$SERVER_NAME/test/file2.php";);
?>
file2.php contains:
file 2 cookies: ";
print_r($_COOKIE);
?>
Expected result:
file 1 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 )
file 2 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 )
Actual result:
--
file 1 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 )
file 2 cookies: Array ( )
--
Edit this bug report at http://bugs.php.net/?id=25929&edit=1
#25929 [Opn->Fbk]: cannot read cookies within included file
ID: 25929 Updated by: [EMAIL PROTECTED] Reported By: joe at kybert dot com -Status: Open +Status: Feedback Bug Type: Variables related Operating System: XP (debug server) PHP Version: 4.3.2 New Comment: 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 4.3.2 is too old. Try using a recent snapshot, as 4.3.4 is just around the corner and this bug (if it is a bug) may already be fixed. (I can't reproduce at any rate.) J Previous Comments: [2003-10-20 19:59:26] joe at kybert dot com Description: Cookie is not readable across multiple files. I have 2 files, file 1 sets a cookie (refresh file after 1st exe so cookie is sent) it then includes file 2, which reads and displays the cookie. Both files are in the same folder on the server, which is /test/ . File 2 fails to read the cookie! Reproduce code: --- file1.php contains: http://$SERVER_NAME/test/file2.php";); ?> file2.php contains: file 2 cookies: "; print_r($_COOKIE); ?> Expected result: file 1 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 ) file 2 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 ) Actual result: -- file 1 cookies: Array ( [LastUser] => ujoe [test] => set_by_file_1 ) file 2 cookies: Array ( ) -- Edit this bug report at http://bugs.php.net/?id=25929&edit=1
#25886 [Bgs]: failed to open stream: Too many open files in Unknown on line 0
ID: 25886
Updated by: [EMAIL PROTECTED]
Reported By: padair at pntsi dot ca
Status: Bogus
Bug Type: *General Issues
Operating System: Solaris 8
PHP Version: 4.3.3
New Comment:
What is your open files limit set to?
Do 'ulimit -a' from a shell -- chances are it's set to
256. Try increasing that to 1024 by opening up /etc/system
as root and making changes to rlim_fd_cur and rlim_fd_max.
Just don't go higher than 1024.
You'll have to reboot your server (the actual machine, not
just the web server) for the changes to take effect.
See 'man -s 4 system' for details.
J
Previous Comments:
[2003-10-16 09:55:46] padair at pntsi dot ca
Here is the page.
";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::apsystemTemperature.0");
echo "Access Point Temperature: $a deg. C";
echo "";
echo "SU DescriptionSignal from APSignal to
APSU TempBytes SentBytes Received";
$numsus=snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suSUCount.0");
for ($sunum=1;$sunum<=$numsus;$sunum++)
{
$assoc=snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suAssociation.$sunum");
if ($assoc=="associated")
{
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suRemarks.$sunum");
echo "$a";
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suRSSIFromAP.$sunum");
$b = round(((120-($a * -1))/70)*100);
echo "$b% ($a dBm)";
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suRSSIFromSU.$sunum");
$b = round(((120-($a * -1))/70)*100);
echo "$b% ($a dBm)";
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suTemperature.$sunum");
echo "$a deg. C";
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suRfInOctets.$sunum");
echo "$a";
echo "";
$a =
snmpget("ap$apnum.pntsi.ca","pntsi-snmp","TRANGOM5830S-MIB::suRfOutOctets.$sunum");
echo "$a";
echo "";
echo "Reboot me";
echo "";
}
else
{
echo "";
print "SU #$sunum is currently not connected.";
echo "";
}
}
echo "";
?>
[2003-10-16 00:54:20] [EMAIL PROTECTED]
If your OS runs out of file descriptors, of course it will error out.
And as you failed to give us a short example script, bogus.
[2003-10-16 00:10:22] padair at pntsi dot ca
Description:
I am getting a "failed to open stream: Too many open files in Unknown
on line 0" error message.
I check similar bug reports but none seemed to apply. I already am
running 4.3.3 where this error was supposed to be fixed.
My config is Solaris 8, Apache 2.0.44, PHP 4.3.3.
My page pulls some simple snmp data and I have a META refresh tag at
the top that refreshes the page every 30 seconds. 99% of the time the
page is ok. Every now and then the error below shows. It goes away on
its own usually by the next refresh.
Actual result:
--
Warning: Unknown(/isp/www/pntsi/stats/snmp.php): failed to open stream:
Too many open files in Unknown on line 0
Warning: (null)(): Failed opening '/isp/www/pntsi/stats/snmp.php' for
inclusion (include_path='.:/usr/local/php4/lib/php') in Unknown on line
0
--
Edit this bug report at http://bugs.php.net/?id=25886&edit=1
#25781 [Opn->Bgs]: strpos doesn't know if the file passed EOF
ID: 25781 Updated by: [EMAIL PROTECTED] Reported By: imscorpio at hotmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Windows 2000 Pro PHP Version: 4.3.3 New Comment: "$my_position = int;" probably isn't doing what you're expecting it to do. It's setting $my_position to the string "int", not making it an integer. (Use a var_dump() and you'll see what I'm talking about.) A for loop or a foreach loop would probably be better in this case anyway, breaking out of it if necessary when strpos() returns false. J Previous Comments: [2003-10-07 15:04:11] imscorpio at hotmail dot com a [2003-10-07 15:02:48] imscorpio at hotmail dot com Description: If you loop a file line by line and searching with strpos() it doesn't know if the file has ended, reached EOF. It will contiue untill crash... Reproduce code: --- //scritp.php Expected result: Nothing to read from or the $haystack has passed the EOF. Actual result: -- Fatal error: Maximum execution time of 30 seconds exceeded in script.php on line 9 Any line within the while() during 30sec it can go up to 65.000 - 70.000 lines -- Edit this bug report at http://bugs.php.net/?id=25781&edit=1
#25494 [Opn->Csd]: array_merge allowing "false" as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org -Status: Open +Status: Closed Bug Type: Arrays related Operating System: Any PHP Version: 4.3.2 New Comment: It can't break BC if the behaviour was undocumented and hence undefined. So either document the behaviour or fix the bug. Anybody relying on undocumented 'features' should know they're at risk for having those behaviours changed. J Previous Comments: [2003-09-18 06:45:48] [EMAIL PROTECTED] It's still inconsistent, and `will throw a warning and fail in 5 for non-array arguments' will break BC without a need for it. [2003-09-18 06:08:03] [EMAIL PROTECTED] Throwing an E_NOTICE error is not breaking anything. [2003-09-18 05:56:38] [EMAIL PROTECTED] This `fix' is inconsistent with array_splice, which allows you to add non-array arguments. (This is also documented.) Also, this `fix' breaks BC. Is this really needed? I'd rather have those functions convert non-array arguments into arrays and then perform their operations like array_splice() does. This has to be documented of course. [2003-09-11 13:57:55] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. array_merge() throws E_NOTICEs now in 4.3.x and will throw a warning and fail in 5 for non-array arguments. J ---- [2003-09-11 12:11:09] [EMAIL PROTECTED] Jay, it's an undocumented feature. If it is not documented and obscure it's developer's risk to use it. So, I think this is a bug and a check for the input parameter should be performed. A warning throwed in the same way as array_intersect() does will be the consistent way. Opening again :) 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494&edit=1
#25573 [Opn]: php compilation error on Sun SPARC Solaris 7
ID: 25573 Updated by: [EMAIL PROTECTED] Reported By: wzaccone at telcordia dot com Status: Open Bug Type: Compile Failure Operating System: Sun Sparc Solaris 7 and 8 PHP Version: 4.3.2 New Comment: It compiles fine here using Solaris 8, gcc 2.95 and bison 1.28. (This is using the latest CVS.) Can you try using 4.3.3 or the latest CVS snapshot? The gcc version might make a difference, too. I haven't used 3.0.1 on Solaris, though, so I can't say for certain. J Previous Comments: [2003-09-17 10:41:09] wzaccone at telcordia dot com it also fails on Solaris 8 as well. gcc -v Reading specs from /usr/local.28/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.0.1/s pecs Configured with: ../configure --with-as=/usr/local/bin/as --with-ld=/usr/local/b in/ld --enable-libgcj Thread model: posix gcc version 3.0.1 which bison /usr/local.28/bin/bison bison -V GNU Bison version 1.28 uname -a SunOS titcher4 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise [2003-09-17 10:30:33] [EMAIL PROTECTED] What versions of bison and gcc are you using? J [2003-09-17 09:46:51] wzaccone at telcordia dot com Description: php 4.3.2 fails to compile using gcc on Sun SPARC Solaris 7. compiles ok on Solaris 8. but not Solaris 7. is there a workaround?? is this fixed in 4.3.3?? output follows below; tried to capture the old build commands before the error occured.. Warren Actual result: -- bison -y /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y mv y.tab.c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c /bin/sh /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/ -DPHP_ATOM_INC -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/include -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/main -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2 -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/Zend -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y: In function `php_parse_date': /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y:933: too many arguments to function `php_gd_parse' *** Error code 1 make: Fatal error: Command failed for target `ext/standard/parsedate.lo' /bin/sh /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/ -DPHP_ATOM_INC -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/include -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/main -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2 -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/Zend -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y: In function `php_parse_date': /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y:933: too many arguments to function `php_gd_parse' *** Error code 1 make: Fatal error: Command failed for target `ext/standard/parsedate.lo' -- Edit this bug report at http://bugs.php.net/?id=25573&edit=1
#25573 [Opn->Fbk]: php compilation error on Sun SPARC Solaris 7
ID: 25573 Updated by: [EMAIL PROTECTED] Reported By: wzaccone at telcordia dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Sun Sparc Solaris 7 PHP Version: 4.3.2 New Comment: What versions of bison and gcc are you using? J Previous Comments: [2003-09-17 09:46:51] wzaccone at telcordia dot com Description: php 4.3.2 fails to compile using gcc on Sun SPARC Solaris 7. compiles ok on Solaris 8. but not Solaris 7. is there a workaround?? is this fixed in 4.3.3?? output follows below; tried to capture the old build commands before the error occured.. Warren Actual result: -- bison -y /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y mv y.tab.c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c /bin/sh /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/ -DPHP_ATOM_INC -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/include -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/main -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2 -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/Zend -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y: In function `php_parse_date': /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y:933: too many arguments to function `php_gd_parse' *** Error code 1 make: Fatal error: Command failed for target `ext/standard/parsedate.lo' /bin/sh /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/standard/ -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/ -DPHP_ATOM_INC -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/include -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/main -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2 -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/Zend -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/TSRM -g -O2 -prefer-pic -c /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.c -o ext/standard/parsedate.lo /usr/local/share/bison.simple: In function `php_gd_parse': /usr/local/share/bison.simple:219: number of arguments doesn't match prototype /usr/local/share/bison.simple:153: prototype declaration /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y: In function `php_parse_date': /FREE_2.4/NMA_WEB/NMA.r131_09-13-2003/install_apache_php/php-4.3.2/ext/standard/parsedate.y:933: too many arguments to function `php_gd_parse' *** Error code 1 make: Fatal error: Command failed for target `ext/standard/parsedate.lo' -- Edit this bug report at http://bugs.php.net/?id=25573&edit=1
#25494 [Opn->Csd]: array_merge allowing "false" as argument (silent when non-array is passed)
ID: 25494 Updated by: [EMAIL PROTECTED] Reported By: enygma at phpdeveloper dot org -Status: Open +Status: Closed Bug Type: Arrays related Operating System: Red Hat Linux PHP Version: 4.3.2 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. array_merge() throws E_NOTICEs now in 4.3.x and will throw a warning and fail in 5 for non-array arguments. J Previous Comments: [2003-09-11 12:11:09] [EMAIL PROTECTED] Jay, it's an undocumented feature. If it is not documented and obscure it's developer's risk to use it. So, I think this is a bug and a check for the input parameter should be performed. A warning throwed in the same way as array_intersect() does will be the consistent way. Opening again :) [2003-09-11 11:50:39] enygma at phpdeveloper dot org it still seems silly to me that a string passed into an array function was taken without so much as a warning. even more strange that it was suddenly treated as an array and merged into the other valid array. maybe a warning would be enough to deter this in the future? [2003-09-11 11:42:26] [EMAIL PROTECTED] If you use var_dump() in place of print_r(), you'd see that it's not a mysterious value, it's 'false'. The boolean value is being converted to an array index in array_merge(). (Any value would produce similar results -- $array1=4; would produce an array value of $last_array[0]==4.) array_intersect() does a type check before it does anything, which is why the warning comes up. While it seems inconsistent, I can't see this being changed because it would affect BC (albeit BC on a somewhat obscure, undocumented feature). Somebody correct me here if I'm wrong. So I'm bogusing it for now. J [2003-09-11 11:42:19] [EMAIL PROTECTED] 1. Please use var_dump() instead of print_r() 2. The value in the merged array is (bool) false [2003-09-11 10:59:27] enygma at phpdeveloper dot org array_merge_recursive() shows the same behavior array_intersect(), however, doesn't and gives a correct warning message 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/25494 -- Edit this bug report at http://bugs.php.net/?id=25494&edit=1
#25494 [Opn->Bgs]: array_merge allowing "false" as argument
ID: 25494
Updated by: [EMAIL PROTECTED]
Reported By: enygma at phpdeveloper dot org
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Red Hat Linux
PHP Version: 4.3.2
New Comment:
If you use var_dump() in place of print_r(), you'd see
that it's not a mysterious value, it's 'false'. The
boolean value is being converted to an array index in
array_merge(). (Any value would produce similar results --
$array1=4; would produce an array value of
$last_array[0]==4.)
array_intersect() does a type check before it does
anything, which is why the warning comes up.
While it seems inconsistent, I can't see this being
changed because it would affect BC (albeit BC on a
somewhat obscure, undocumented feature). Somebody correct
me here if I'm wrong. So I'm bogusing it for now.
J
Previous Comments:
[2003-09-11 11:42:19] [EMAIL PROTECTED]
1. Please use var_dump() instead of print_r()
2. The value in the merged array is (bool) false
[2003-09-11 10:59:27] enygma at phpdeveloper dot org
array_merge_recursive() shows the same behavior
array_intersect(), however, doesn't and gives a correct warning message
[2003-09-11 10:57:27] enygma at phpdeveloper dot org
Description:
Code:
---
$array1=false;
$array2=array("test"=>"1","testing"=>"2");
$last_array=array_merge($array1,$array2);
echo ""; print_r($last_array); echo "";
---
Result:
---
Array
(
[0] =>
[test] => 1
[testing] => 2
)
---
Please note that not only does array_merge allow the "false" to be
passed in, but when it is, a mysterious [0] appears in the results
(null array value?)
Reproduce code:
---
"1","testing"=>"2");
$last_array=array_merge($array1,$array2);
echo ""; print_r($last_array); echo "";
?>
Expected result:
Either an "invalid argument" for the "false" being passed in, or no
extra Null array value appended to the resulting array.
Actual result:
--
Array
(
[0] =>
[test] => 1
[testing] => 2
)
--
Edit this bug report at http://bugs.php.net/?id=25494&edit=1
#25289 [Opn]: PHP segmentation fault
ID: 25289
Updated by: [EMAIL PROTECTED]
Reported By: skissane at ics dot mq dot edu dot au
Status: Open
Bug Type: Reproducible crash
Operating System: RedHat Linux 9
PHP Version: 4.3.3
New Comment:
A shorter script:
bar1 = "foobar1";
$foo->bar2 = "foobar2";
foreach ($foo as $b->name => $b) {
}
?>
The foreach loop is the problem. You're creating a new
stdClass object with $b->name for the key, then using $b
itself for the value, thus destroying the key used in
stdClass.
Looks to me like a ZE1 issue. Doesn't occur in HEAD.
J
Previous Comments:
[2003-08-28 18:10:01] skissane at ics dot mq dot edu dot au
Sorry about giving so many testcases (only just learning how to do
this), but I finally have a 20-line reproduce script:
obj_enum as $enum) {
foreach ($enum->obj_enumvalue as $enumvalue) {
}
$i = 0;
foreach ($enum->obj_enumvalue as $enumvalue->name => $enumvalue) {
$out = " " . $enum->prefix . "_" .
$enumvalue->name . " => \"" . $enumvalue->name . "\"";
if ($i++ < count($enum->obj_enumvalue)-1) {
}
}
}
?>
It depends on the test.dat data file I included with my earlier test
cases.
[2003-08-28 11:00:37] skissane at ics dot mq dot edu dot au
Okay, I tried a bit harder, and I have now reduced it down to a single
400 line .php file, plus three associated data files which the .php
file unserializes. This results in a segmentation fault when run from
the command line or Apache.
You can get the latest one from
http://www.iips.mq.edu.au/bugs/testcase3.tgz
[2003-08-28 10:31:21] skissane at ics dot mq dot edu dot au
I can't work out what exactly is causing it, and so can't come up with
a 20 line test. I have reduced it down to a smaller set of files, at
http://www.iips.mq.edu.au/bugs/testcase.tgz
If you have any suggestions of how I can trim this down to a smaller
test case, I'll try.
[2003-08-28 10:07:26] [EMAIL PROTECTED]
Please provide a short script (max 20 lines), without any external
dependancies, such as database or includes().
(_one_ script, not dozens)
[2003-08-28 07:19:19] skissane at ics dot mq dot edu dot au
Description:
PHP segfaults.
Reproduce code:
---
Reproduce code can be found at:
http://www.iips.mq.edu.au/bugs/
File datamodel/cms-datamodel-php.php causes crash.
Through trial and error (insertion of "echo" and "exit" statements, I
believe I have isolated the segfault to the function
ObjectGenerator_PHP::_generateEnums() in the file
appgen/ObjectGenerator_PHP.inc, but not 100% sure).
Segfault occurs both on command line php and through Apache.
PHP was compiled myself using: './configure'
'--with-apxs2=/usr/sbin/apxs' '--with-mysql=/usr/' '--without-mssql'
'--with-ldap' '--with-curl=/usr'
Expected result:
No segfault
Actual result:
--
Starting program: /usr/local/bin/php cms-datamodel-php.php
Program received signal SIGSEGV, Segmentation fault.
0x42074760 in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0 0x42074760 in _int_free () from /lib/tls/libc.so.6
#1 0x42073786 in free () from /lib/tls/libc.so.6
#2 0x08104302 in _efree (ptr=0x82cd0bc) at
/home/skissane/php-4.3.3/Zend/zend_alloc.c:265
#3 0x0810a85a in _zval_ptr_dtor (zval_ptr=0x8312c48) at
zend_execute.h:44
#4 0x08115e70 in zend_hash_destroy (ht=0x832c41c) at
/home/skissane/php-4.3.3/Zend/zend_hash.c:553
#5 0x08110aae in _zval_dtor (zvalue=0xbfffa9e0) at
/home/skissane/php-4.3.3/Zend/zend_variables.c:51
#6 0x0811f611 in execute (op_array=0x81eaf7c) at
/home/skissane/php-4.3.3/Zend/zend_execute.c:1452
#7 0x0811e653 in execute (op_array=0x81eadd4) at
/home/skissane/php-4.3.3/Zend/zend_execute.c:1660
#8 0x0811e653 in execute (op_array=0x81a2004) at
/home/skissane/php-4.3.3/Zend/zend_execute.c:1660
#9 0x08111fd5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/skissane/php-4.3.3/Zend/zend.c:885
#10 0x080ecb87 in php_execute_script (primary_file=0xbfffddc0) at
/home/skissane/php-4.3.3/main/main.c:1723
#11 0x081234bb in main (argc=2, argv=0xbfffde44) at
/home/skissane/php-4.3.3/sapi/cli/php_cli.c:818
#12 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) frame 6
#6 0x0811f611 in execute (op_array=0x81eaf7c) at
/home/skissane/php-4.3.3/Zend/zend_execute.c:1452
1452
zendi_zval_dtor(EX(Ts)[EX(opline)->op1.u.var].tmp_var);
(gdb)
--
Edit this bug report at http://bugs.php.net/?id=25289&edit=1
#25270 [Bgs]: error with php
ID: 25270 Updated by: [EMAIL PROTECTED] Reported By: steve at 69cash dot com Status: Bogus -Bug Type: *General Issues +Bug Type: Unknown/Other Function Operating System: win2k PHP Version: 4.3.3 New Comment: I guess this is bogus, then. J Previous Comments: [2003-08-27 11:32:39] [EMAIL PROTECTED] *sigh* [2003-08-27 10:16:17] steve at 69cash dot com hey.. i got it.. all you have to do is use the php.exe instead of the .dll Thanks tho [2003-08-27 07:21:38] steve at 69cash dot com Description: PHP has encountered an Access Violation at 77FC8DBD I keep getting that error on my php page. I am getting alot of traffic.. close to 50 clicks per second. It seems to only be doing this 50% of the time. After a hour or so the computer will jump to 100% cpu usage and the web page will stop loading. Does anybody know how to fix this? I really need help. Thanks Reproduce code: --- There is no code.. It is just anything with php Expected result: display the page? ;) Actual result: -- PHP has encountered an Access Violation at 77FC8DBD That is all it says.. -- Edit this bug report at http://bugs.php.net/?id=25270&edit=1
#25272 [Opn->Bgs]: undefined exception in php.exe
ID: 25272 Updated by: [EMAIL PROTECTED] Reported By: Fabian dot Bernecker at web dot de -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Win2k SP1 PHP Version: 4.3.3 New Comment: You're doing some infinite recursion here. Eventually you'll hit a wall. (There are logic errors in your script -- look at "$cur++" and "!$cur>=$i" for instance.) Besides, brute forcing MD5 would take forever. Even if you could do a trillion attempts per second it would still take you from now until the Sun exploded to complete the brute force attack. J Previous Comments: [2003-08-27 08:48:41] Fabian dot Bernecker at web dot de Description: I wrote a script which causes an unknown exception in php.exe. I wasn't able to locate any error in the script. Reproduce code: --- http://mandrill.fuxx0r.net/c++/paste.php?p=578 Expected result: I wrote j4f a small script for bruteforcing md5. Actual result: -- I wanted to test the script. It caused an unknown exception in php.exe. -- Edit this bug report at http://bugs.php.net/?id=25272&edit=1
#25261 [Opn->Bgs]: Inconsistent time zone from date()
ID: 25261 Updated by: [EMAIL PROTECTED] Reported By: radio_jed at hotmail dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Win32 (XP Corp. Pro) PHP Version: 4.3.2 New Comment: Since this is a duplicate, it's bogus. J Previous Comments: [2003-08-26 16:11:46] radio_jed at hotmail dot com Found bug #23467, this user is having the same problem I am. I will add to that thread, rather than keep searching here. [2003-08-26 15:57:48] radio_jed at hotmail dot com The time zone in Windows is correct, I was not negligent in setting PST -- I just checked. [2003-08-26 15:55:39] radio_jed at hotmail dot com Description: I am running PHP 4.3.2 with Apache2 (yes, I'm sorry), and I'm trying to use date() to display my computer's time zone. I am in PST (Pacific Standard Time, America/Los_Angeles), but date() is returning "BST" when I use "T" in date()'s format (the other parameters in the format string don't influence this at all.) I'm not sure what BST is. Unchecking "automatically set clock for daylight savings time changes" in Windows' time applet did not fix this problem, either, unlike bug #24912 suggests; not even after a reboot. Install info: PHP 4.3.2 ZIP binary from php.net (I did not compile my own) Apache/Win32 2.0.47, using Apache2 SAPI module Windows XP Corporate Professional Edition No relevant differences in php.ini. Reproduce code: --- /* that's my original problem, this demonstrates as well: */ Expected result: modified 1340 PST Actual result: -- modified 1340 BST -- Edit this bug report at http://bugs.php.net/?id=25261&edit=1
#25233 [Opn->Bgs]: strtotime() fails on dates < Jan 1 1970
ID: 25233 Updated by: [EMAIL PROTECTED] Reported By: alain at valain dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Linux Redhat 7.3 PHP Version: 4.3.2 New Comment: This is a glibc problem. glibc is just following the POSIX standard now. See http://bugs.php.net/bug.php?id=23475 J Previous Comments: [2003-08-25 05:31:34] alain at valain dot com Description: The strtotime() function fails with -1 on dates that are < Jan 1 1970. This makes other PHP functions like date() to return Jan 1 1970 on the "faulty" timestamp -1. Reproduce code: --- \n"; echo "\n"; echo "\n"; echo "Date de naissance: " . $usernaiss . "\n"; echo "\n"; echo "\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=25233&edit=1
#25190 [Opn->Bgs]: Segmentation fault
ID: 25190
Updated by: [EMAIL PROTECTED]
Reported By: gabor at netway dot hu
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Debian Linux
PHP Version: 4.3.3RC4
New Comment:
So by the looks of it, this is using ADOdb, which means
this is a third-party application and isn't necessarily a
PHP problem. You'll have to contact the ADOdb developers
and see what they say.
I don't know what OVS, but if it's another third-party
application, contact them as well.
J
Previous Comments:
[2003-08-21 11:05:23] gabor at netway dot hu
Thank you :-).
[2003-08-21 10:58:59] gabor at netway dot hu
the code is:
function OVS_Z050($ORA_SESS_ID){
global $conn;
$Z050_query="
BEGIN
msie_logout_session_proc (:sessid,:ipaddr,:result_rc);
END;
";
$stmt = $conn->PrepareSP($Z050_query);
$conn->Parameter($stmt,$ORA_SESS_ID,"sessid",27);
$conn->Parameter($stmt,getenv("REMOTE_ADDR"),"ipaddr",15);
$conn->Parameter($stmt,$rc, "result_rc",12);
$conn->Execute($stmt);
if ($rc==500)
$msg = 'Logoff succeeded';
else {
$msg="ERROR(".$rc."): ";
if ($rc==(-501)){
$msg.="Logoff ok, but session timed out!";
echo "
alert('".$msg."');
";
}
if ($rc==(-550)){
$msg.="LOGGING ERROR!";
echo "
alert('".$msg."');
";
}
}
return $msg;
}
[2003-08-21 10:47:36] [EMAIL PROTECTED]
Is this caused by some sort of third-party application?
What is OVS? Do you have a self-contained example that can
actually be reproduced? What does the function OVS_Z050()
do?
Unless you can answer these questions, this is likely
bogus.
J
[2003-08-21 09:28:53] gabor at netway dot hu
Description:
apache crash, and no more request.
Reproduce code:
---
include("head.php");
OVS_Z050($_SESSION["ovs_session"]);
sleep(5);
session_destroy();
?>
Expected result:
[Mon Aug 18 08:24:55 2003] [notice] Apache/1.3.26 Ben-SSL/1.48 (Unix)
Debian GNU/Linux PHP/4.3.3RC4-dev configured -- resuming normal
operations
[Mon Aug 18 08:24:55 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache-ssl/suexec)
[Mon Aug 18 08:24:55 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Mon Aug 18 10:48:18 2003] [notice] child pid 344 exit signal
Segmentation fault (11)
[Mon Aug 18 10:48:54 2003] [notice] child pid 341 exit signal
Segmentation fault (11)
[Mon Aug 18 10:49:37 2003] [notice] child pid 366 exit signal
Segmentation fault (11)
/usr/src/php4-STABLE-200308080930/Zend/zend_execute.c(1611) : Freeing
0x08151FAC (12 bytes), script=/var/www/ovs/ovs.members/php/Z050.php
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(295) : Freeing
0x0814CE14 (14520 bytes), script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 2 times
Zend/zend_language_scanner.c(4619) : Freeing 0x08151EF4 (11 bytes),
script=/var/www/xx.php
Last leak repeated 118 times
Zend/zend_language_scanner.c(4484) : Freeing 0x08151EB4 (9 bytes),
script=/var/www/xx.php
Last leak repeated 80 times
Zend/zend_language_scanner.c(4492) : Freeing 0x08151D2C (20 bytes),
script=/var/www/xx.php
Last leak repeated 80 times
Zend/zend_language_scanner.c(3072) : Freeing 0x0814AA24 (84 bytes),
script=/var/www/xx.php
Last leak repeated 2 times
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(65) : Freeing
0x0814B5A4 (4 bytes), script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 2 times
Zend/zend_language_scanner.c(3911) : Freeing 0x0814B564 (16 bytes),
script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 5 times
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(854) : Freeing
0x0814B474 (13 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
Last leak repeated 1 time
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(230) : Freeing
0x081464D4 (12 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(1761) : Freeing
0x08145E84 (9 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(1745) : Freeing
0x08145D2C (9 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
locat
#25188 [Opn]: array_compact
ID: 25188
Updated by: [EMAIL PROTECTED]
Reported By: jari at reputation dot fi
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.3.3RC4
New Comment:
Wouldn't array_filter() provide what you're looking for?
J
Previous Comments:
[2003-08-21 08:45:52] jari at reputation dot fi
Description:
Removes all array elements with empty values from a given array.
Didn't manage to find command similar to this.
Reproduce code:
---
function array_compact($thisArray) {
for($i = 0; $i < sizeof($thisArray); $i++) {
if($thisArray[$i] != "") {
$newArray[] = $thisArray[$i];
}
}
return $newArray;
}
Expected result:
Array
(
[0] => banana
[1] =>
[2] => apple
)
->
Array
(
[0] => banana
[1] => apple
)
--
Edit this bug report at http://bugs.php.net/?id=25188&edit=1
#25190 [Opn->Fbk]: Segmentation fault
ID: 25190
Updated by: [EMAIL PROTECTED]
Reported By: gabor at netway dot hu
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Debian Linux
PHP Version: 4.3.3RC4
New Comment:
Is this caused by some sort of third-party application?
What is OVS? Do you have a self-contained example that can
actually be reproduced? What does the function OVS_Z050()
do?
Unless you can answer these questions, this is likely
bogus.
J
Previous Comments:
[2003-08-21 09:28:53] gabor at netway dot hu
Description:
apache crash, and no more request.
Reproduce code:
---
include("head.php");
OVS_Z050($_SESSION["ovs_session"]);
sleep(5);
session_destroy();
?>
Expected result:
[Mon Aug 18 08:24:55 2003] [notice] Apache/1.3.26 Ben-SSL/1.48 (Unix)
Debian GNU/Linux PHP/4.3.3RC4-dev configured -- resuming normal
operations
[Mon Aug 18 08:24:55 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache-ssl/suexec)
[Mon Aug 18 08:24:55 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Mon Aug 18 10:48:18 2003] [notice] child pid 344 exit signal
Segmentation fault (11)
[Mon Aug 18 10:48:54 2003] [notice] child pid 341 exit signal
Segmentation fault (11)
[Mon Aug 18 10:49:37 2003] [notice] child pid 366 exit signal
Segmentation fault (11)
/usr/src/php4-STABLE-200308080930/Zend/zend_execute.c(1611) : Freeing
0x08151FAC (12 bytes), script=/var/www/ovs/ovs.members/php/Z050.php
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(295) : Freeing
0x0814CE14 (14520 bytes), script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 2 times
Zend/zend_language_scanner.c(4619) : Freeing 0x08151EF4 (11 bytes),
script=/var/www/xx.php
Last leak repeated 118 times
Zend/zend_language_scanner.c(4484) : Freeing 0x08151EB4 (9 bytes),
script=/var/www/xx.php
Last leak repeated 80 times
Zend/zend_language_scanner.c(4492) : Freeing 0x08151D2C (20 bytes),
script=/var/www/xx.php
Last leak repeated 80 times
Zend/zend_language_scanner.c(3072) : Freeing 0x0814AA24 (84 bytes),
script=/var/www/xx.php
Last leak repeated 2 times
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(65) : Freeing
0x0814B5A4 (4 bytes), script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 2 times
Zend/zend_language_scanner.c(3911) : Freeing 0x0814B564 (16 bytes),
script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 5 times
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(854) : Freeing
0x0814B474 (13 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
Last leak repeated 1 time
/usr/src/php4-STABLE-200308080930/Zend/zend_opcode.c(230) : Freeing
0x081464D4 (12 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(1761) : Freeing
0x08145E84 (9 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(1745) : Freeing
0x08145D2C (9 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
/usr/src/php4-STABLE-200308080930/Zend/zend_compile.c(2025) : Freeing
0x0814597C (8 bytes), script=/var/www/ovs/ovs.members/php/xx.php
/usr/src/php4-STABLE-200308080930/Zend/zend_variables.c(111) : Actual
location (location was relayed)
Last leak repeated 5 times
Zend/zend_language_scanner.c(4399) : Freeing 0x0814617C (3 bytes),
script=/var/www/ovs/ovs.members/php/xx.php
Last leak repeated 1 time
Zend/zend_language_scanner.c(4710) : Freeing 0x081410AC (9 bytes),
script=/var/www/ovs/ovs.members/php/xx.php
[Mon Aug 18 10:50:32 2003] [notice] child pid 342 exit signal
Segmentation fault (11)
[Mon Aug 18 10:51:52 2003] [notice] child pid 340 exit signal
Segmentation fault (11)
[Mon Aug 18 10:53:22 2003] [notice] child pid 339 exit signal
Segmentation fault (11)
[Mon Aug 18 14:03:12 2003] [notice] child pid 472 exit signal
Segmentation fault (11)
[Mon Aug 18 14:11:22 2003] [notice] child pid 433 exit signal
Segmentation fault (11)
[Mon Aug 18 14:12:32 2003] [notice] child pid 338 exit signal
Segmentation fault (11)
[Mon Aug 18 14:13:23 2003] [notice] child pid 434 exit signal
Segmentation fault (11)
[Mon Aug 18 14:15:11 2003] [notice] child pid 473 exit signal
Segmentation fault (11)
[Mon Aug 18 14:15:30 2003] [notice] child pid 443 exit signal
Segmentation fault (11)
[Mon Aug 18 14:15:57 2003] [notice] child pid 474 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=25190&edit=1
#24680 [Opn->Bgs]: MP3 Functions
ID: 24680 Updated by: [EMAIL PROTECTED] Reported By: stephen_sandison at msn dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Any PHP Version: Irrelevant New Comment: simul-post, bogusifying again. J Previous Comments: [2003-07-16 10:45:20] [EMAIL PROTECTED] I very much doubt this functionality will be added to the core of PHP. A PECL extension is much more likely. There is a PEAR module for ID3 tags called MP3_Id that you might want to look at. FWIW, I've written an extension for ID3 tags (not the PEAR module, this is in C++) but I haven't released it yet. J [2003-07-16 10:43:48] [EMAIL PROTECTED] This functionality is already available as a PEAR package, please see http://pear.php.net/package-info.php?package=MP3_ID for more information. Other fileformats could be implemented likewise, please feel free to contribute code :) [2003-07-16 10:31:45] stephen_sandison at msn dot com Description: Would it be possible to add functions related to media types such as mp3, ogg, wma etc... So that ID3 tags could be read/edited/deleted without the need for custom functions. I know of quite a few people who would appreciate this functionality. Regards, Stephen Web Developer Goss Interactive Ltd. (www.gossinteractive.com) -- Edit this bug report at http://bugs.php.net/?id=24680&edit=1
#24680 [Bgs->Opn]: MP3 Functions
ID: 24680 Updated by: [EMAIL PROTECTED] Reported By: stephen_sandison at msn dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: Irrelevant New Comment: I very much doubt this functionality will be added to the core of PHP. A PECL extension is much more likely. There is a PEAR module for ID3 tags called MP3_Id that you might want to look at. FWIW, I've written an extension for ID3 tags (not the PEAR module, this is in C++) but I haven't released it yet. J Previous Comments: [2003-07-16 10:43:48] [EMAIL PROTECTED] This functionality is already available as a PEAR package, please see http://pear.php.net/package-info.php?package=MP3_ID for more information. Other fileformats could be implemented likewise, please feel free to contribute code :) [2003-07-16 10:31:45] stephen_sandison at msn dot com Description: Would it be possible to add functions related to media types such as mp3, ogg, wma etc... So that ID3 tags could be read/edited/deleted without the need for custom functions. I know of quite a few people who would appreciate this functionality. Regards, Stephen Web Developer Goss Interactive Ltd. (www.gossinteractive.com) -- Edit this bug report at http://bugs.php.net/?id=24680&edit=1
#24645 [Bgs]: ereg_replace fails to strtolower replaced string
ID: 24645
Updated by: [EMAIL PROTECTED]
Reported By: nek at capsule dot org
Status: Bogus
Bug Type: Regexps related
Operating System: Linux
PHP Version: 4.3.1
New Comment:
ereg_replace() is working exactly as expected. The
inner-most functions are processed first, so strtolower()
gets processed before ereg_replace(). Therefore,
"HREF=\"\\1\"" is being sent through strtolower(), not "". strtolower() has no idea
what \1 means other than \1. This is totally expected
behaviour.
Try doing something writing like foo(bar($s)) and write
your own functions for foo() and bar(). bar() is always
performed first. Same thing in this case.
The behaviour you're proposing is just not the expected
bevariour, hence the bogusness.
J
Previous Comments:
[2003-07-14 09:43:11] nek at capsule dot org
doh... tab then return = submit form.. sorry
i said :
THIS IS A TEST LINK";
$newsaff =
ereg("HREF=\"([^\"]+)\"",$newsaff,$newsreplace);
for ($i=1;$i
maybe there's a simplier solution, that's coded from scratch ;)
but yes indeed, that's complicated and a non bogus ereg_replace would
be from great help :)
thanks
[2003-07-14 09:39:50] nek at capsule dot org
you mean something like :
THIS IS A TEST LINK";
$newsaff =
ereg("HREF=\"([^\"]+)\"",$newsaff,$newsreplace);
for ($i=1;$i
[2003-07-14 09:21:06] [EMAIL PROTECTED]
That's correct, so this is bogus. Try using
ereg()/preg_match() with the optional registers used in
the third argument to get the results you're looking for.
J
[2003-07-14 09:19:55] nek at capsule dot org
well,
maybe the matching string should be considered as a normal one, so we
can use some functions on it.
this would render ereg_replace function even more powerfull, isn't it ?
[2003-07-14 09:09:01] b_ulrich at t-online dot de
Using strtolower("HREF=\"\\1\"") as parameter is like using
"href=\"\\1\"" directly.
First the strtolower is processed and then that result is used as
parameter.
You have to change your search/replace pattern to get what you want.
The function works correct.
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/24645
--
Edit this bug report at http://bugs.php.net/?id=24645&edit=1
#24645 [Opn->Bgs]: ereg_replace fails to strtolower replaced string
ID: 24645
Updated by: [EMAIL PROTECTED]
Reported By: nek at capsule dot org
-Status: Open
+Status: Bogus
Bug Type: Regexps related
Operating System: Linux
PHP Version: 4.3.1
New Comment:
That's correct, so this is bogus. Try using
ereg()/preg_match() with the optional registers used in
the third argument to get the results you're looking for.
J
Previous Comments:
[2003-07-14 09:19:55] nek at capsule dot org
well,
maybe the matching string should be considered as a normal one, so we
can use some functions on it.
this would render ereg_replace function even more powerfull, isn't it ?
[2003-07-14 09:09:01] b_ulrich at t-online dot de
Using strtolower("HREF=\"\\1\"") as parameter is like using
"href=\"\\1\"" directly.
First the strtolower is processed and then that result is used as
parameter.
You have to change your search/replace pattern to get what you want.
The function works correct.
[2003-07-14 08:39:01] nek at capsule dot org
sorry, it's php 4.3.1 and not 4.3.2
[2003-07-14 08:37:18] nek at capsule dot org
Description:
Hi,
i'm trying to replace a portion of string by its strtolowered
equivalent
see reproduce code and results below : it should give
"href=javascript:comment()" but only "HREF" is lowered, not the
matching string \1
Reproduce code:
---
THIS IS A TEST LINK";
$newsaff =
ereg_replace("HREF=\"([^\"]+)\"",strtolower("HREF=\"\\1\""),$newsaff);
print $newsaff;
?>
Expected result:
THIS IS A TEST LINK
Actual result:
--
THIS IS A TEST LINK
--
Edit this bug report at http://bugs.php.net/?id=24645&edit=1
#24548 [Asn->Fbk]: get_browser() does not return platform
ID: 24548
Updated by: [EMAIL PROTECTED]
Reported By: mikx at mikx dot de
-Status: Assigned
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: *
PHP Version: 4.3.2
Assigned To: jay
New Comment:
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
This has been fixed in CVS for PHP 5 and I've merged the
changes over. Try the next snapshot and see if it provides
better matches. It reports Win2000 now for your example,
others should work as well.
J
Previous Comments:
[2003-07-09 07:33:04] [EMAIL PROTECTED]
Jay, can you look into this?
[2003-07-09 06:12:33] alexandre dot alapetite at risoe dot dk
It seems that there is a problem with the get_browser() function.
It is not respecting the browscap.ini format.
For example (with IE6.0 Win2000) in the browscap.ini we can find
[IE 6.0]
which are the generic values for all IE6 browsers.
And is the this wrong one that is returned by get_browser() since the
"IE 6.0" pattern is contained in the user agent string "Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.0; Q312461)".
The good match in browscap.ini for IE6 Win2000 should be
[Mozilla/4\.0 (compatible; MSIE 6\.0.*;.*Windows NT 5\.0.*).*]
The solution for IE6 is to replace in browscap.ini
[IE 6.0] by [Internet Explorer 6.0]
and parent=IE 6.0 by parent=Internet Explorer 6.0
This way it will return also the platform, the browser, etc...
But PHP should update the way they analyse regular expressions from
browscap.ini which are in fact of the form
[^xxx$]. That meens that expressions in browscap.ini are always full
pattern and not just a peace.
Hope it will be corrected soon.
[2003-07-08 18:44:56] mikx at mikx dot de
Seems to be a bug in 4.3.2 - downgraded to 4.3.0 and get_browser() is
able to detect the platform of much more HTTP_USER_AGENT strings now.
[2003-07-08 16:44:11] mikx at mikx dot de
Just figured out that get_browser() does not return a fixed set of
informations - the platform information is only given if resolved.
It can't resolve most versions of Internet Explorer 6, not sure if this
is a bug or a weakness of the browscap.ini.
[2003-07-08 16:20:15] mikx at mikx dot de
Description:
The object returned from get_browser() function does not contain the
platform information as described in the documentation and as usual in
prior versions.
It's more a missing feature than a bug, but it brings some old scripts
relying on this feature into trouble.
The browscap.ini is the latest "official" one from Gary Keith.
Reproduce code:
---
$browser = get_browser();
foreach ($browser as $name => $value) {
print "$name $value \n";
}
--
Edit this bug report at http://bugs.php.net/?id=24548&edit=1
#24494 [Opn->Bgs]: incorrect value for texte in array
ID: 24494 Updated by: [EMAIL PROTECTED] Reported By: bibifoc23 at yahoo dot fr -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: all PHP Version: 4.3.2 New Comment: This is expected behaviour, I believe. $array['TM'] is not an array, it's a string, but strings can be treated like arrays. So 'TM' gets converted to 0 given PHP's type juggling rules, and $array['TM'][0] is 't', so it's working as expected. J Previous Comments: [2003-07-04 08:08:05] bibifoc23 at yahoo dot fr Description: hello, I get strange behaviour with array: 'test', 'autre dossier' => 'texte' ) ; print_r ( $array ); echo $array['TM']['TM']."\n"; ?> the echo command return the first character of string. But $array['TM'] is not an array, so i expext to have an error wen i call $array['TM']['TM']. But PHP convert the second index to 0. Thanks Reproduce code: --- 'test', 'autre dossier' => 'texte' ) ; print_r ( $array ); echo $array['TM']['TM']."\n"; ?> Expected result: return error or warning. Actual result: -- return the first character of the string -- Edit this bug report at http://bugs.php.net/?id=24494&edit=1
#12312 [Opn]: array_mt_rand() ?
ID: 12312 Updated by: [EMAIL PROTECTED] Reported By: lramsey at crystalorb dot net Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4.3 PHP Version: 4.0.6 New Comment: There's a patch for php-src HEAD at http://bugs.tutorbuddy.com/download.php/php5.array_mt_rand.patch Adds array_mt_rand(). Rewriting the existing functions would be bad for BC if anybody is relying on their current behaviour. J Previous Comments: [2003-06-06 17:33:04] [EMAIL PROTECTED] Why not just rewrite array_rand() and shuffle() to instead use mt_srand()? It is "superior" after all... And seeding takes place automatically as of PHP 4.2.0 [2003-06-06 14:54:06] [EMAIL PROTECTED] There is no 'array_shuffle()' and shuffle() uses rand too. Having array_mt_rand() is quite good idea. [2003-05-31 10:37:15] [EMAIL PROTECTED] Does array_shuffle() solve this? [2001-07-22 21:23:20] lramsey at crystalorb dot net As the mt_rand() algorithim creates better random numbers than rand(), would it be possible to include in future releases of the language to include a version of array_rand() that uses mt_rand()? -- Edit this bug report at http://bugs.php.net/?id=12312&edit=1
#20221 [Bgs]: str_replace
ID: 20221
Updated by: [EMAIL PROTECTED]
Reported By: panacode at skynet dot be
Status: Bogus
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Really? Then what is the value of $trans_tbl['ASCII'][13]?
That looks zero-length to me.
php_str_replace_in_subject() previously moved the search
array forward and didn't move the replace array. This has
since been fixed in CVS.
J
Previous Comments:
[2003-06-24 11:39:17] heinz at hhombergs dot de
But as you can see the search and the replace array in the function
have no 0 length values and all three arrays are of the same size.
[2003-06-20 10:09:05] [EMAIL PROTECTED]
In php_str_replace_in_subject(), if a value in the search
array is of 0 length, the search array internal pointer is
moved ahead, but not the replace array. Shouldn't they
both be moved ahead? This would produce the results
panacode is expecting, but it would break BC, but I don't
see any documentation that covers this behaviour. Unless
I'm blind, of course, which I may be.
J
[2003-06-19 16:29:17] heinz at hhombergs dot de
Sorry but there is a bug in the str_replace function. Reproduced under
4.2.2 and 4.3.2
function recode_charset($string,$cs_from,$cs_to) {
$trans_tbl["ASCII"] = array("&", "¡", "¢", "£", "¤", "¥", "¦", "§",
"¨", "©", "ª", "«", "¬", "", "®", "¯", "°", "±", "²", "³", "´", "µ",
"¶", "·", "¸", "¹", "º", "»", "¼", "½", "¾", "¿", "À", "Á", "Â", "Ã",
"Ä", "Å", "Æ", "Ç", "È", "É", "Ê", "Ë", "Ì", "Í", "Î", "Ï", "Ð", "Ñ",
"Ò", "Ó", "Ô", "Õ", "Ö", "×", "Ø", "Ù", "Ú", "Û", "Ü", "Ý", "Þ", "ß",
"à", "á", "â", "ã", "ä", "å", "æ", "ç", "è", "é", "ê", "ë", "ì", "í",
"î", "ï", "ð", "ñ", "ò", "ó", "ô", "õ", "ö", "÷", "ø", "ù", "ú", "û",
"ü", "ý", "þ", "ÿ");
$trans_tbl["UNICODE"] = array("&", "¡", "¢", "£",
"¤", "¥", "¦", "§", "¨", "©", "ª",
"«", "¬", "", "®", "¯", "°", "±",
"²", "³", "´", "µ", "¶", "·", "¸",
"¹", "º", "»", "¼", "½", "¾", "¿",
"À", "Á", "Â", "Ã", "Ä", "Å", "Æ",
"Ç", "È", "É", "Ê", "Ë", "Ì", "Í",
"Î", "Ï", "Ð", "Ñ", "Ò", "Ó", "Ô",
"Õ", "Ö", "×", "Ø", "Ù", "Ú", "Û",
"Ü", "Ý", "Þ", "ß", "à", "á", "â",
"ã", "ä", "å", "æ", "ç", "è", "é",
"ê", "ë", "ì", "í", "î", "ï", "ð",
"ñ", "ò", "ó", "ô", "õ", "ö", "÷",
"ø", "ù", "ú", "û", "ü", "ý", "þ",
"ÿ");
$trans_tbl["HTML"] = array("&", "¡", "¢", "£",
"¤", "¥", "¦", "§", "¨", "©", "ª",
"«", "¬", "", "®", "¯", "°", "±",
"²", "³", "´", "µ", "¶", "·",
"¸", "¹", "º", "»", "¼", "½",
"¾", "¿", "À", "Á", "Â", "Ã",
"Ä", "Å", "Æ", "Ç", "È", "É",
"Ê", "Ë", "Ì", "Í", "Î", "Ï",
"Ð", "Ñ", "Ò", "Ó", "Ô", "Õ",
"Ö", "×", "Ø", "Ù", "Ú", "Û",
"Ü", "Ý", "Þ", "ß", "à", "á",
"â", "ã", "ä", "å", "æ", "ç",
"è", "é", "ê", "ë", "ì", "í",
"î", "ï", "ð", "ñ", "ò", "ó",
"ô", "õ", "ö", "÷", "ø", "ù",
"ú", "û", "ü", "ý", "þ", "ÿ");
return str_replace($trans_tbl[$cs_from], $trans_tbl[$cs_to],
$string);
}
$string = recode_charset('ÄäÖöÜüß','ASCII','HTML');
will produce ÃãÛûÕõÞ
but ÄäÜüÖöß is correct.
[2002-11-02 17:46:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
[2002-11-02 17:43:08] panacode at skynet dot be
Sorry for bothering (and for my writing errors).
There actually is another function in PHP that has the
behaviour that I expect: strtr(str, arr)
$vReplace['@gill'] = '@doubleyou';
$vReplace['@doubleyou'] = '@bates';
$sSubject = "@gill @doubleyou is not my friend";
$sResult = strtr($sSubject, $vReplace);
echo $sResult;
// will output "@doubleyou @bates is not my friend"
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/20221
--
Edit this bug report at http://bugs.php.net/?id=20221&edit=1
#20221 [Bgs]: str_replace
ID: 20221
Updated by: [EMAIL PROTECTED]
Reported By: panacode at skynet dot be
Status: Bogus
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
In php_str_replace_in_subject(), if a value in the search
array is of 0 length, the search array internal pointer is
moved ahead, but not the replace array. Shouldn't they
both be moved ahead? This would produce the results
panacode is expecting, but it would break BC, but I don't
see any documentation that covers this behaviour. Unless
I'm blind, of course, which I may be.
J
Previous Comments:
[2003-06-19 16:29:17] heinz at hhombergs dot de
Sorry but there is a bug in the str_replace function. Reproduced under
4.2.2 and 4.3.2
function recode_charset($string,$cs_from,$cs_to) {
$trans_tbl["ASCII"] = array("&", "¡", "¢", "£", "¤", "¥", "¦", "§",
"¨", "©", "ª", "«", "¬", "", "®", "¯", "°", "±", "²", "³", "´", "µ",
"¶", "·", "¸", "¹", "º", "»", "¼", "½", "¾", "¿", "À", "Á", "Â", "Ã",
"Ä", "Å", "Æ", "Ç", "È", "É", "Ê", "Ë", "Ì", "Í", "Î", "Ï", "Ð", "Ñ",
"Ò", "Ó", "Ô", "Õ", "Ö", "×", "Ø", "Ù", "Ú", "Û", "Ü", "Ý", "Þ", "ß",
"à", "á", "â", "ã", "ä", "å", "æ", "ç", "è", "é", "ê", "ë", "ì", "í",
"î", "ï", "ð", "ñ", "ò", "ó", "ô", "õ", "ö", "÷", "ø", "ù", "ú", "û",
"ü", "ý", "þ", "ÿ");
$trans_tbl["UNICODE"] = array("&", "¡", "¢", "£",
"¤", "¥", "¦", "§", "¨", "©", "ª",
"«", "¬", "", "®", "¯", "°", "±",
"²", "³", "´", "µ", "¶", "·", "¸",
"¹", "º", "»", "¼", "½", "¾", "¿",
"À", "Á", "Â", "Ã", "Ä", "Å", "Æ",
"Ç", "È", "É", "Ê", "Ë", "Ì", "Í",
"Î", "Ï", "Ð", "Ñ", "Ò", "Ó", "Ô",
"Õ", "Ö", "×", "Ø", "Ù", "Ú", "Û",
"Ü", "Ý", "Þ", "ß", "à", "á", "â",
"ã", "ä", "å", "æ", "ç", "è", "é",
"ê", "ë", "ì", "í", "î", "ï", "ð",
"ñ", "ò", "ó", "ô", "õ", "ö", "÷",
"ø", "ù", "ú", "û", "ü", "ý", "þ",
"ÿ");
$trans_tbl["HTML"] = array("&", "¡", "¢", "£",
"¤", "¥", "¦", "§", "¨", "©", "ª",
"«", "¬", "", "®", "¯", "°", "±",
"²", "³", "´", "µ", "¶", "·",
"¸", "¹", "º", "»", "¼", "½",
"¾", "¿", "À", "Á", "Â", "Ã",
"Ä", "Å", "Æ", "Ç", "È", "É",
"Ê", "Ë", "Ì", "Í", "Î", "Ï",
"Ð", "Ñ", "Ò", "Ó", "Ô", "Õ",
"Ö", "×", "Ø", "Ù", "Ú", "Û",
"Ü", "Ý", "Þ", "ß", "à", "á",
"â", "ã", "ä", "å", "æ", "ç",
"è", "é", "ê", "ë", "ì", "í",
"î", "ï", "ð", "ñ", "ò", "ó",
"ô", "õ", "ö", "÷", "ø", "ù",
"ú", "û", "ü", "ý", "þ", "ÿ");
return str_replace($trans_tbl[$cs_from], $trans_tbl[$cs_to],
$string);
}
$string = recode_charset('ÄäÖöÜüß','ASCII','HTML');
will produce ÃãÛûÕõÞ
but ÄäÜüÖöß is correct.
[2002-11-02 17:46:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
[2002-11-02 17:43:08] panacode at skynet dot be
Sorry for bothering (and for my writing errors).
There actually is another function in PHP that has the
behaviour that I expect: strtr(str, arr)
$vReplace['@gill'] = '@doubleyou';
$vReplace['@doubleyou'] = '@bates';
$sSubject = "@gill @doubleyou is not my friend";
$sResult = strtr($sSubject, $vReplace);
echo $sResult;
// will output "@doubleyou @bates is not my friend"
[2002-11-02 14:22:23] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-02 13:04:24] panacode at skynet dot be
str_replace when used with with arrays,
for every element in the search/replace arrays
a simple replace in the source string (rather than
using an external string) is performed.
This causes an unexpected result like
if one of the replace values includes
a search value it will be replaced in a subsequent
replacing action.
If this is a feature rather than a bug (which I doubt)
please state it in the documentation.
An example:
$vSearch[] = '@gill';
$vSearch[] = '@doubleyou';
$vReplace[] = '@doubleyou';
$vReplace[] = '@bates';
$sSubject = "@gill is my friend";
$sResult = str_replace($vSearch, $vReplace, $sSubject);
echo $sResult;
// will output "@bates is not my friend" instead
// of "@doubleyou is not my friend"
Best regards,
Eugen Fernea
IT Manager
Panacode Software
rue de la Station, 1/1
7090 Braine-Le-Comte
Belgium
E-mail: [EMAIL PROTECTED]
Phone: +32 067/48 58 94
Mobile: +32 (0)472 95 15 48
Web: http://www.panacode.com
--
Edit this bug report at http://bugs.php.net/?id=20221&edit=1
#24243 [Opn]: Browscap causes segfault
ID: 24243 Updated by: [EMAIL PROTECTED] Reported By: neon at neon-line dot net Status: Open Bug Type: Zend Engine 2 problem Operating System: FreeBSD 4.8-stable PHP Version: 5CVS-2003-06-18 (dev) New Comment: As a temporary fix, you can put quotation marks around "LWP::Simple" where it says browser=LWP::Simple in browscap.ini. It's the double-colons that are messing things up, as zend_get_constant is trying to do a class lookup on the lwp class, which will obviously fail. Perhaps a flag argument could be added to zend_get_constant to prevent checking for '::' and that class lookup? (Or rather, zend_get_constant_ex or whatever with new defines for BC?) J Previous Comments: [2003-06-18 07:28:39] [EMAIL PROTECTED] This is some ZE2 issue. [2003-06-18 06:37:49] neon at neon-line dot net Browscap causes this segfault. Without it everything goes like it should. [2003-06-18 06:12:58] neon at neon-line dot net Description: Segmentation fault with php -v Reproduce code: --- php -v Expected result: PHP 5.0.0-dev (cli) (built: Jun 18 2003 08:06:52) (DEBUG) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0, Copyright (c) 1998-2003 Zend Technologies Actual result: -- (gdb) run -v Starting program: /usr/home/neon/php5-200306180930/sapi/cli/php -v Program received signal SIGSEGV, Segmentation fault. 0x810c437 in zend_hash_find (ht=0x0, arKey=0xbfbfe988 "lwp", nKeyLength=4, pData=0xbfbfe9c8) at /usr/home/neon/php5-200306180930/Zend/zend_hash.c:840 840 nIndex = h & ht->nTableMask; (gdb) bt #0 0x810c437 in zend_hash_find (ht=0x0, arKey=0xbfbfe988 "lwp", nKeyLength=4, pData=0xbfbfe9c8) at /usr/home/neon/php5-200306180930/Zend/zend_hash.c:840 #1 0x8100732 in zend_lookup_class (name=0xbfbfe988 "lwp", name_length=3, ce=0xbfbfe9c8) at /usr/home/neon/php5-200306180930/Zend/zend_execute_API.c:703 #2 0x80ff2b8 in zend_get_constant (name=0x81d0880 "LWP::Simple", name_len=11, result=0xbfbfea00) at /usr/home/neon/php5-200306180930/Zend/zend_constants.c:251 #3 0x80f71c8 in zend_ini_get_constant (result=0xbfbfea70, name=0xbfbfead0) at Zend/zend_ini_parser.c:121 #4 0x80f77a8 in ini_parse () at Zend/zend_ini_parser.c:928 #5 0x80f72ea in zend_parse_ini_file (fh=0xbfbff8f0, unbuffered_errors=1, ini_parser_cb=0x8091560 , arg=0x8170e60) at Zend/zend_ini_parser.c:176 #6 0x809180c in zm_startup_browscap (type=1, module_number=2) at /usr/home/neon/php5-200306180930/ext/standard/browscap.c:165 #7 0x808cc6f in zm_startup_basic (type=1, module_number=2) at /usr/home/neon/php5-200306180930/ext/standard/basic_functions.c:1084 #8 0x8109d46 in zend_startup_module (module=0x8167460) at /usr/home/neon/php5-200306180930/Zend/zend_API.c:1126 #9 0x80ded27 in php_startup_extensions (ptr=0x816fc88, count=7) at /usr/home/neon/php5-200306180930/main/main.c:1222 #10 0x812f7b1 in php_startup_internal_extensions () at main/internal_functions_cli.c:62 #11 0x80df115 in php_module_startup (sf=0x816fbe0, additional_modules=0x0, num_additional_modules=0) at /usr/home/neon/php5-200306180930/main/main.c:1387 #12 0x812e8aa in main (argc=2, argv=0xbfbffb88) at /usr/home/neon/php5-200306180930/sapi/cli/php_cli.c:592 -- Edit this bug report at http://bugs.php.net/?id=24243&edit=1
#24109 [Opn->Bgs]: Console window
ID: 24109 Updated by: [EMAIL PROTECTED] Reported By: npeelman at cfl dot rr dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: WinXP Pro PHP Version: 4.3.2 New Comment: Isn't this exactly what the ncurses extension provides? http://www.php.net/ncurses J Previous Comments: [2003-06-10 05:17:58] npeelman at cfl dot rr dot com I would like to see the ability to open a 'console screen' when running PHP from the command prompt. Several functions would be needed for setting size and depth of screen as well as color and cursor control. -- Edit this bug report at http://bugs.php.net/?id=24109&edit=1
#23984 [Opn->Bgs]: chr(0) in pattern string causes string truncation
ID: 23984
Updated by: [EMAIL PROTECTED]
Reported By: ltfrench at vt dot edu
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Redhat 8.0
PHP Version: 4.3.1
New Comment:
I believe this is a limitation of the PCRE library. From
the PCRE man page:
"The pattern is a C string terminated by a binary zero,
and is passed in the argument pattern. ... The subject
string is passed as a pointer in subject, a length in
length, and a starting offset in startoffset. Unlike the
pattern string, it may contain binary zero characters."
So, you can't have NULL characters in the pattern string.
You can use str_replace() to replace those NULL
characters, though.
J
Previous Comments:
[2003-06-03 12:13:52] ltfrench at vt dot edu
Ok, this will teach me to try to write new test cases. The first test
case was bogus, I'm a boob.
The problem I am really having with is with preg_replace().
This generates
Warning: No ending delimiter '/' found in /home/www/web_root/lance.php
on line 19
Which leads me to believe that my $pattern string got truncated without
the trailing / when used in preg_replace.
[2003-06-03 10:09:07] [EMAIL PROTECTED]
PHP is looking for a variable named $nullwithnull so to make this work,
you must use "string{$null}withnull"...
[2003-06-03 08:56:54] ltfrench at vt dot edu
This problem is very similar to: http://bugs.php.net/bug.php?id=14580
and also http://bugs.php.net/bug.php?id=18341 but seems to have cropped
up again.
Inserting a null character into a string with the chr() function causes
the string to be truncated.
Output:
stringwithnull
string
15
6
I encountered this with a generic php 4.3.1 setup.
--
Edit this bug report at http://bugs.php.net/?id=23984&edit=1
#23967 [Fbk]: number_format() returns 0 all the time
ID: 23967
Updated by: [EMAIL PROTECTED]
Reported By: russ at zerotech dot net
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 4.3.2
New Comment:
I'm betting that this is related to that gcc bug that
breaks the modf() call in glibc. It's cropped up on gentoo
systems before, and usually happens when your
CFLAGS/CXXFLAGS are set to something like '-march=pentium4
-O3'. Use pentium3 or -mhost=i686 instead.
See http://bugs.php.net/bug.php?id=22887 for details.
J
Previous Comments:
[2003-06-03 10:20:44] matt at coderweb dot com
The latest stable CVS snapshot does not work. I can also confirm
number_format() working in PHP 4.3.0 on Gentoo, but not working in PHP
4.3.2 on Gentoo.
[2003-06-03 01:45:55] [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
Joey, it doesn't crash... so you can not make a backtrace...
Anyway, this should be fixed in the latest CVS, so please try the
snapshot.
[2003-06-02 22:58:41] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can't duplicate this. Tried several different GCC versions to no
avail.
[2003-06-02 20:28:56] russ at zerotech dot net
Also, forgot to add. Earlier in the day I noticed various web
applications that use number_format() were returning either 0, or
random garbage such as:
0.F0
0.:;
0,0;
etc.
[2003-06-02 20:24:51] russ at zerotech dot net
number_format() returns 0, all the time, regardless of what was
entered.
[EMAIL PROTECTED]:~$ php -r 'echo number_format(400); echo "\n";';
0
[EMAIL PROTECTED]:~$ php -r 'echo number_format(600); echo "\n";';
0
[EMAIL PROTECTED]:~$ php -r 'echo number_format(600, 2); echo "\n";';
0.00
[EMAIL PROTECTED]:~$ php -r 'echo number_format(600, 5); echo "\n";';
0.0
[EMAIL PROTECTED]:~$ php -r 'echo number_format("600", 5); echo "\n";';
0.0
[EMAIL PROTECTED]:~$
Also affects the Apache SAPI module, obviously since they make the call
to the same function. Worked fine of course in 4.3.1. I just recently
upgraded to 4.3.2 and noticed it stopped working.
--
Edit this bug report at http://bugs.php.net/?id=23967&edit=1
#23050 [Bgs]: Header Location error
ID: 23050
Updated by: [EMAIL PROTECTED]
Reported By: tomas dot marklund at datortek dot orebro dot se
Status: Bogus
Bug Type: IIS related
Operating System: WinXP
PHP Version: 4.3.1
New Comment:
Use the full, absolute URI.
header("Location: http://www.example.com/foo.php";);
The RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616.html
J
Previous Comments:
[2003-04-04 12:37:59] tomas dot marklund at datortek dot orebro dot se
Ok how to make it work then???
[2003-04-04 11:09:26] [EMAIL PROTECTED]
header("Location:foo.php"); violates the RFC. Not bug in PHP.
[2003-04-04 07:15:25] tomas dot marklund at datortek dot orebro dot se
I installed a new php4.3.1 on a new IIS5 on a new computer with WinXP
SP1.
And then all my scripts with the
Header("location:index.php") funktion stopt working.
The only error message that i get is:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Note: It worked before!!
I hope this is no bug! but a error i've made
PHP 4.3.1 installer.zip
MySQL 4.0 (if this matter)
code--
--code
--
Edit this bug report at http://bugs.php.net/?id=23050&edit=1
#23040 [Opn]: Periodic Segmentation Faults
ID: 23040 Updated by: [EMAIL PROTECTED] Reported By: tim at danan dot com Status: Open Bug Type: Reproducible crash Operating System: Redhat 8 PHP Version: 4.3.1 New Comment: It looks like putenv() is the last thing called from PHP land before the crash, so that's a start. J Previous Comments: [2003-04-03 16:36:46] tim at danan dot com I've not been able to narrow it down to anything that specific yet. I've only just narrowed it down to this page in the past day or so. Unfortunately, the page almost 700 lines long, so I wouldn't call it "short". I'll continue to try to narrow it down to see if I can isolate a function, but it may not be easy since the page tends to load fine 50-60 times in a row, then blow up. There's probably something unique going on in the crash instances, but I've not located it yet. If you'd like the long script I'll be happy to provide it. I'm not an expert at reading dumps by any means. Does anything jump out at you? Are there any hints of some place I might be able to look to help narrow things down? [2003-04-03 15:51:54] [EMAIL PROTECTED] Do you have a short test script that can reproduce this segfault? J [2003-04-03 15:22:52] tim at danan dot com I have a page that is generating repeated segmentation faults on a Redhat 8 system running Apache 1.3.27 and PHP 4.3.1. It is part of a forum system (FudForum) that, unforunately, I didn't write. MySQL and sessions are both involved. The faults are not occurring on every use, but seem to occur about once an hour. Once a seg fault appears I tend to see 4-5 of them in succession, then they disappear again for an hour or so. [Thu Apr 3 14:18:51 2003] [notice] child pid 8668 exit signal Segmentation fault (11) I was able to generate a backtrace by running httpd -X in gdb. (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40262195 in calloc () from /lib/libc.so.6 (gdb) bt #0 0x40262195 in calloc () from /lib/libc.so.6 #1 0x40260f60 in realloc () from /lib/libc.so.6 #2 0x402176cf in putenv () from /lib/libc.so.6 #3 0x402175f8 in putenv () from /lib/libc.so.6 #4 0x404e6b41 in zif_putenv (ht=1, return_value=0x86fb92c, this_ptr=0x0, return_value_used=0) at /usr/local/src/php-4.3.1/ext/standard/basic_functions.c:1353 #5 0x405ab626 in execute (op_array=0x86ec4f0) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1596 #6 0x405ab859 in execute (op_array=0x86ea418) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640 #7 0x405ab859 in execute (op_array=0x86459ac) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640 #8 0x4059a321 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.3.1/Zend/zend.c:864 #9 0x40564f6b in php_execute_script (primary_file=0xb390) at /usr/local/src/php-4.3.1/main/main.c:1573 #10 0x405b0546 in apache_php_module_main (r=0x841801c, display_source_mode=0) at /usr/local/src/php-4.3.1/sapi/apache/sapi_apache.c:55 #11 0x405b13e6 in send_php (r=0x841801c, display_source_mode=0, filename=0x8419dfc "/var/www/html/forum/index.php") at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:556 #12 0x405b145f in send_parsed_php (r=0x841801c) at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:571 #13 0x080cd6f4 in ap_invoke_handler () #14 0x080e209a in process_request_internal () #15 0x080e20fa in ap_process_request () #16 0x080d92e2 in child_main () #17 0x080d94a8 in make_child () #18 0x080d960f in startup_children () #19 0x080d9c3c in standalone_main () #20 0x080da474 in main () #21 0x40202907 in __libc_start_main () from /lib/libc.so.6 GCC Version: gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) My php config is VERY simple: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-mysql \ --with-pgsql \ --with-pspell \ --enable-debug I'm sure there is a great deal of additional information I can provide, and I will do so quite willingly. My apologies if I've overlooked anything in this report. -- Edit this bug report at http://bugs.php.net/?id=23040&edit=1
#23040 [Opn]: Periodic Segmentation Faults
ID: 23040 Updated by: [EMAIL PROTECTED] Reported By: tim at danan dot com Status: Open Bug Type: Reproducible crash Operating System: Redhat 8 PHP Version: 4.3.1 New Comment: Do you have a short test script that can reproduce this segfault? J Previous Comments: [2003-04-03 15:22:52] tim at danan dot com I have a page that is generating repeated segmentation faults on a Redhat 8 system running Apache 1.3.27 and PHP 4.3.1. It is part of a forum system (FudForum) that, unforunately, I didn't write. MySQL and sessions are both involved. The faults are not occurring on every use, but seem to occur about once an hour. Once a seg fault appears I tend to see 4-5 of them in succession, then they disappear again for an hour or so. [Thu Apr 3 14:18:51 2003] [notice] child pid 8668 exit signal Segmentation fault (11) I was able to generate a backtrace by running httpd -X in gdb. (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x40262195 in calloc () from /lib/libc.so.6 (gdb) bt #0 0x40262195 in calloc () from /lib/libc.so.6 #1 0x40260f60 in realloc () from /lib/libc.so.6 #2 0x402176cf in putenv () from /lib/libc.so.6 #3 0x402175f8 in putenv () from /lib/libc.so.6 #4 0x404e6b41 in zif_putenv (ht=1, return_value=0x86fb92c, this_ptr=0x0, return_value_used=0) at /usr/local/src/php-4.3.1/ext/standard/basic_functions.c:1353 #5 0x405ab626 in execute (op_array=0x86ec4f0) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1596 #6 0x405ab859 in execute (op_array=0x86ea418) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640 #7 0x405ab859 in execute (op_array=0x86459ac) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640 #8 0x4059a321 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.3.1/Zend/zend.c:864 #9 0x40564f6b in php_execute_script (primary_file=0xb390) at /usr/local/src/php-4.3.1/main/main.c:1573 #10 0x405b0546 in apache_php_module_main (r=0x841801c, display_source_mode=0) at /usr/local/src/php-4.3.1/sapi/apache/sapi_apache.c:55 #11 0x405b13e6 in send_php (r=0x841801c, display_source_mode=0, filename=0x8419dfc "/var/www/html/forum/index.php") at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:556 #12 0x405b145f in send_parsed_php (r=0x841801c) at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:571 #13 0x080cd6f4 in ap_invoke_handler () #14 0x080e209a in process_request_internal () #15 0x080e20fa in ap_process_request () #16 0x080d92e2 in child_main () #17 0x080d94a8 in make_child () #18 0x080d960f in startup_children () #19 0x080d9c3c in standalone_main () #20 0x080da474 in main () #21 0x40202907 in __libc_start_main () from /lib/libc.so.6 GCC Version: gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) My php config is VERY simple: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --with-mysql \ --with-pgsql \ --with-pspell \ --enable-debug I'm sure there is a great deal of additional information I can provide, and I will do so quite willingly. My apologies if I've overlooked anything in this report. -- Edit this bug report at http://bugs.php.net/?id=23040&edit=1
#23039 [Opn->WFx]: Apache CRASH with illegal code (C++ style)
ID: 23039
Updated by: [EMAIL PROTECTED]
Reported By: a dot eibach at gmx dot net
-Status: Open
+Status: Wont fix
Bug Type: Reproducible crash
Operating System: Win98 SE
PHP Version: 4.3.1
New Comment:
It's not so crazy. You've just got some endless recursion
there, which is why it doesn't happen when you uncomment
the contact constructor. When the contact object is
instantiated, the employer constructor is called in the
absence of a contact constructor. Since a new contact
object is instanitated in the employer constructor, you
get recursion, as the employer constructor is effectively
calling itself. You'll eventually run out of memory or
something similarly strange will happen, hence the
segfault. You'll get the same results if you do "function
foo() { return foo(); } foo();"
I don't imagine this will be fixed. It's not PHP's fault
is somebody codes an endless recursion loop.
J
Previous Comments:
[2003-04-03 13:33:44] a dot eibach at gmx dot net
Hi.
What is illegal code? Code with the intention to break something. But
sometimes it's even a bad mistake causing this (inheriting a wrong
class or deriving from an illegal class or...)
The following stuff is really ILLEGAL code. YOU SHOULD NEVER PROGRAM
LIKE THIS. ;) But Apache shouldn't GPF, too. The Apache people warped
me over here because they said that this is no Apache issue. May they
be right.
As you can see...
The code is *very* narrowed down. It's definitely not _that_ simple
IRL.
Main class is 'db_entry'. Class 'contact' is derived from employer,
which is derived itself from db_entry.
Now we get ILLEGAL. We create a new 'contact' member object by directly
(!!!) instantiating contact from the db_entry constructor. (Of course,
we should instantiate 'employer', because contact is created inside
too. But we want the crash, don't we :))
Crazy thing is that PHP doesn't complain about anything if this is done
with *existing* 'contact()' constructor.
If this is missing or disabled ('//' part), Apache crashes.
OS: Win98 SE
Apache: 1.3.27
PHP: 4.3.1 (stable)
--script--
contactman = new contact();
}
}
class contact extends employer
{
// function contact() // this is the constructor and it's
MISSING!!!
// {// --> crash
// }
}
class db_entry
{
var $ct_entry;
function db_entry()
{
/* generate indirect member object by illegally
instantiating an object TWO hierarchy steps below!!! */
$this->ct_entry = new contact();
// -> crash!
}
}
$newentr = new db_entry();
echo "OK";
?>
--
Edit this bug report at http://bugs.php.net/?id=23039&edit=1
#23009 [Opn->Csd]: pg_select with timestamp
ID: 23009
Updated by: [EMAIL PROTECTED]
Reported By: leoguti at iband dot net
-Status: Open
+Status: Closed
Bug Type: PostgreSQL related
Operating System: ANY
PHP Version: 4.3.1
Assigned To: helly
New Comment:
This should be fixed in CVS now.
J
Previous Comments:
[2003-04-01 16:49:44] [EMAIL PROTECTED]
Ah sorry, now i know what you meant.
[2003-04-01 16:18:37] [EMAIL PROTECTED]
Read the manual on PostgreSQL:
uni=# create table t ( t timestamp with time zone);
CREATE
uni=# insert into t values ('2003-04-01 22:00:00. GMT');
INSERT 167462 1
[2003-04-01 15:41:38] leoguti at iband dot net
I can't do that the function work with timestamp with time zone data
type.
I have the table
create table proob(
field_proob timestamp with time zone
);
an I tried to do
"2003-03-30 22:47:52.657715-05");
echo pg_insert($conexion,"proob",$a);
?>
With other data types this function work but with this don't.
--
Edit this bug report at http://bugs.php.net/?id=23009&edit=1
#23007 [Opn]: "`OnUpdateLong' undeclared here (not in a function)" during make
ID: 23007 Updated by: [EMAIL PROTECTED] Reported By: joe at recompiled dot org Status: Open Bug Type: Compile Failure Operating System: Mandrake 9.1 PHP Version: 4CVS-2003-04-01 (stable) New Comment: How did you pull down php4? OnUpdateLong is only in HEAD/php5, not in the php4 branch. When you checkout php4, make sure you use 'cvs co -r PHP_4_3 php4'. J Previous Comments: [2003-04-01 13:46:13] joe at recompiled dot org Hi folks, Having tons of trouble getting php4 to run on my new Mandrake 9.1 install. After getting an error I saw as fixed in cvs, I downloaded the cvs php4 tree today and started into it. buildconf then 'configure --with-apxs2=/usr/local/apache2/bin/apxs" then build: === [EMAIL PROTECTED] php4]# make gcc -Iext/ctype/ -I/usr/src/programs/php4/ext/ctype/ -DPHP_ATOM_INC -I/usr/src/programs/php4/include -I/usr/src/programs/php4/main -I/usr/src/programs/php4 -I/usr/src/programs/php4/Zend -I/usr/src/programs/php4/ext/xml/expat -I/usr/src/programs/php4/TSRM -g -O2 -c /usr/src/programs/php4/ext/ctype/ctype.c -o ext/ctype/ctype.o && echo > ext/ctype/ctype.lo gcc -I/usr/src/programs/php4/ext/mysql/libmysql -Iext/mysql/ -I/usr/src/programs/php4/ext/mysql/ -DPHP_ATOM_INC -I/usr/src/programs/php4/include -I/usr/src/programs/php4/main -I/usr/src/programs/php4 -I/usr/src/programs/php4/Zend -I/usr/src/programs/php4/ext/xml/expat -I/usr/src/programs/php4/TSRM -g -O2 -c /usr/src/programs/php4/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.o && echo > ext/mysql/php_mysql.lo /usr/src/programs/php4/ext/mysql/php_mysql.c:310: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:310: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:310: (near initialization for `ini_entries[0].on_modify') /usr/src/programs/php4/ext/mysql/php_mysql.c:310: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:310: (near initialization for `ini_entries[0]') /usr/src/programs/php4/ext/mysql/php_mysql.c:311: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:311: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:311: (near initialization for `ini_entries[1].on_modify') /usr/src/programs/php4/ext/mysql/php_mysql.c:311: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:311: (near initialization for `ini_entries[1]') /usr/src/programs/php4/ext/mysql/php_mysql.c:312: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:312: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:312: (near initialization for `ini_entries[2].on_modify') /usr/src/programs/php4/ext/mysql/php_mysql.c:312: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:312: (near initialization for `ini_entries[2]') /usr/src/programs/php4/ext/mysql/php_mysql.c:313: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:313: (near initialization for `ini_entries[3]') /usr/src/programs/php4/ext/mysql/php_mysql.c:314: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:314: (near initialization for `ini_entries[4]') /usr/src/programs/php4/ext/mysql/php_mysql.c:315: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:315: (near initialization for `ini_entries[5]') /usr/src/programs/php4/ext/mysql/php_mysql.c:316: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:316: (near initialization for `ini_entries[6]') /usr/src/programs/php4/ext/mysql/php_mysql.c:317: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:317: (near initialization for `ini_entries[7]') /usr/src/programs/php4/ext/mysql/php_mysql.c:318: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:318: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:318: (near initialization for `ini_entries[8]') /usr/src/programs/php4/ext/mysql/php_mysql.c:319: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:319: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:319: `OnUpdateLong' undeclared here (not in a function) /usr/src/programs/php4/ext/mysql/php_mysql.c:319: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:319: (near initialization for `ini_entries[9].on_modify') /usr/src/programs/php4/ext/mysql/php_mysql.c:319: initializer element is not constant /usr/src/programs/php4/ext/mysql/php_mysql.c:319: (near initialization for `ini_entries[9]') /usr/src/programs/php4/ext/mysql/php_mysql.c:320: initializer element is not constant /usr/src/programs/php4/ext/m
#22887 [Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887 Updated by: [EMAIL PROTECTED] Reported By: josh at chatgris dot com Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux /w apache2 PHP Version: 4.3.1 New Comment: I haven't had any problems on my system using pentium3. When I came across the problem, I was using pentium4 and I switched it over to pentium3, so my system is slowly being converted. (I have so much on this system, I can't re-emerge everything at once as I need it for work, so I'm doing it bit by bit.) Fwiw, my CFLAGS is "-march=pentium3 -O3 -pipe -fomit-frame-pointer", on a P4 Dell laptop. Slight correction to previous post: I meant CFLAGS, not the USE flag in make.conf. J Previous Comments: [2003-03-28 11:23:12] josh at chatgris dot com Thank you for the suggestion!! I am going to try and compile my entire gentoo system from scratch using mcpu=i686 (I feel kinda iffy using march=pentium3 on a pentium4). I'll respond as soon as I have new information. Thanks again Josh. [2003-03-28 11:16:00] [EMAIL PROTECTED] This is most likely being caused by over-optimization when compiling. I had a similar problem on my gentoo box, and the problem was traced back to over-optimizing when compiling glibc. (var_dump() was printing some weird floats, and I believe this problem is similar, as both use modf() at some point.) Basically, tone down the optimizations a bit. If you compile glibc with CFLAGS along the lines of "-march=pentium4 -O3...", modf() starts dying. The solution (for gentoo, at least) is to modify your USE flag in make.conf to use -march=pentium3 if you're using pentium4 and re-emerge glibc, then recompile PHP. gcc has problems with march pentium4 spitting out bad instructions, so you should stay away from it, even if you're actually on a Pentium 4. Use march=pentium3 or mcpu=i686 instead. There are threads on the gentoo forums about this, and newer versions of portage mention it in the make.conf comments. If this is indeed the problem, it affects python, too, fwiw. J [2003-03-28 10:27:01] josh at chatgris dot com I believe the problem is related.. For example, we are both using Pentium$ CPU's.. sprintf works fine on my Athlon, but not my pentium4... In addition, his example produced the same output on my machine. and I've tried putting the float in a variable, float as a string it alwasy returns the same so I am pretty sure that the problem is within sprintf.. Could anyone tell me where the sprintf code is in php? I don't mind messing with it and trying to figure out what is wrong... Josh. [2003-03-28 04:41:25] [EMAIL PROTECTED] Works fine here (Gentoo with glibc 2.3.2), using php5 cvs from two days ago (cli). -tal [2003-03-28 02:43:18] [EMAIL PROTECTED] Just tried PHP4.3.2/5 with CLI/Apache1 on mdk/winxp. All work fine and the code that might cause the problems is not sapi dependant. The external message you pointed to is different because he used a string to be printed with %f. That means it must first be converted to a number and then printed. 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/22887 -- Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#22887 [Opn]: sprintf( "%.2f", 10.75 ); returns "0.00"
ID: 22887
Updated by: [EMAIL PROTECTED]
Reported By: josh at chatgris dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux /w apache2
PHP Version: 4.3.1
New Comment:
This is most likely being caused by over-optimization when
compiling. I had a similar problem on my gentoo box, and
the problem was traced back to over-optimizing when
compiling glibc. (var_dump() was printing some weird
floats, and I believe this problem is similar, as both use
modf() at some point.)
Basically, tone down the optimizations a bit. If you
compile glibc with CFLAGS along the lines of
"-march=pentium4 -O3...", modf() starts dying. The
solution (for gentoo, at least) is to modify your USE flag
in make.conf to use -march=pentium3 if you're using
pentium4 and re-emerge glibc, then recompile PHP.
gcc has problems with march pentium4 spitting out bad
instructions, so you should stay away from it, even if
you're actually on a Pentium 4. Use march=pentium3 or
mcpu=i686 instead. There are threads on the gentoo forums
about this, and newer versions of portage mention it in
the make.conf comments.
If this is indeed the problem, it affects python, too,
fwiw.
J
Previous Comments:
[2003-03-28 10:27:01] josh at chatgris dot com
I believe the problem is related.. For example, we are
both using Pentium$ CPU's..
sprintf works fine on my Athlon, but not my pentium4...
In addition, his example produced the same output on my
machine. and I've tried putting the float in a variable,
float as a string it alwasy returns the same so I am
pretty sure that the problem is within sprintf..
Could anyone tell me where the sprintf code is in php? I
don't mind messing with it and trying to figure out what
is wrong...
Josh.
[2003-03-28 04:41:25] [EMAIL PROTECTED]
Works fine here (Gentoo with glibc 2.3.2), using php5 cvs from two days
ago (cli).
-tal
[2003-03-28 02:43:18] [EMAIL PROTECTED]
Just tried PHP4.3.2/5 with CLI/Apache1 on mdk/winxp. All
work fine and the code that might cause the problems is not sapi
dependant.
The external message you pointed to is different because he used a
string to be printed with %f. That means it must first be converted to
a number and then printed.
[2003-03-28 00:08:36] josh at chatgris dot com
I am not the only one experiencing this problem.. plus it
seems to round the number randomly for example
echo sprintf('%.2f', '8.7586206896551724');
returns 10.00
the person who had this problem's post is here
http://forums.gentoo.org/viewtopic.php?t=38470&highlight=sprintf
[2003-03-27 21:55:28] [EMAIL PROTECTED]
It cannot be a general php problem as nobody here can reproduce it. It
has to something related to either Apache2 or some other factor unique
to your machine.
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/22887
--
Edit this bug report at http://bugs.php.net/?id=22887&edit=1
#21497 [Bgs]: include() of XML document fails
ID: 21497 Updated by: [EMAIL PROTECTED] Reported By: polone at townnews dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat Linux 6.2 PHP Version: 4.3.0 New Comment: There's no such thing as tags are recognized. ; NOTE: Using short tags should be avoided when developing applications or ; libraries that are meant for redistribution, or deployment on PHP ; servers which are not under your control, because short tags may not ; be supported on the target server. For portable, redistributable code, ; be sure not to use short tags. [2003-03-24 20:29:47] mike at sydel dot net I am also experiencing this problem. Indeed, polone is right that disabling short tags shouldn't be the solution. I say this because a lot of people are already using to simply echo variables. If they for one case also encountered the same problem as we have, then he has to rewrite the code where http://bugs.php.net/21497 -- Edit this bug report at http://bugs.php.net/?id=21497&edit=1
#22737 [Opn]: Rename empty()
ID: 22737 Updated by: [EMAIL PROTECTED] Reported By: php dot net at trenkner dot de Status: Open Bug Type: Feature/Change Request Operating System: ANY PHP Version: 4.3.0 New Comment: So what's your plan to mitigate BC problems? What about the users who have written their own functions called is_empty() and is_set()? You can't just replace something as commonly used as isset() or empty(). If you really want this functionality, wrap a userland function around empty() and isset(), because the odds of this changing are infintesimally small. J Previous Comments: [2003-03-16 12:26:24] php dot net at trenkner dot de Maybe this is a FAQ but I didn't found it, so... The function empty() seems to be named inconsistently. We say is_null, is_string, is_object so why there is no function is_empty()? BTW isset() is also not in sync :-( I would like to see a function is_empty() which behaves in the same way then empty(), same for is_set() replacing isset(). -- Edit this bug report at http://bugs.php.net/?id=22737&edit=1
#22386 [Opn]: Using browscap causes segfault
ID: 22386
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2003-02-23 (dev)
New Comment:
This should be fixed in CVS. In addition to the fix, an
optional bool parameter has been added that changes the
return type to an array.
The format of browser_name_pattern has changed slightly,
but I doubt that will be much of a problem. The
get_browser() function seems a bit more accurate now, as
after doing some tests on 240+ browser IDs, it's returning
platform with more accuracy ("linux", "freebsd", etc. now
for Konqueror instead of "unix") and also finding Mozilla
on Mac, which 4.3.x seem to miss.
J
Previous Comments:
[2003-02-23 10:22:34] [EMAIL PROTECTED]
After compiling a fresh PHP5, a simple call to 'php -v' provides a
segfault. Note that commenting out the browscap in php.ini or running
php like 'php -n -v' causes the segfault to go away. Thanks to Wez for
the diagnosis and here's the backtrace:
#0 0x0815d325 in zend_objects_store_put (object=0x401a803c,
dtor=0x815b400 , clone=0) at
/cvs/php5/Zend/zend_objects_API.c:68
#1 0x0815b4ac in zend_objects_new (object=0xbfffe870,
class_type=0x81b4978) at /cvs/php5/Zend/zend_objects.c:79
#2 0x0814e14b in _object_and_properties_init (arg=0x81ca6c8,
class_type=0x81b4978, properties=0x81ca6f8, __zend_filename=0x8173160
"/cvs/php5/ext/standard/browscap.c", __zend_lineno=133) at
/cvs/php5/Zend/zend_API.c:664
#3 0x0808f868 in php_browscap_parser_cb (arg1=0xbfffe950, arg2=0x0,
callback_type=2, arg=0x81ae8e0) at
/cvs/php5/ext/standard/browscap.c:133
#4 0x0813661a in ini_parse () at /cvs/php5/Zend/zend_ini_parser.y:205
#5 0x0813605e in zend_parse_ini_file (fh=0xb7b4,
unbuffered_errors=1 '\001', ini_parser_cb=0x808f6b8
, arg=0x81ae8e0) at
/cvs/php5/Zend/zend_ini_parser.y:156
#6 0x0808f9c2 in zm_startup_browscap (type=1, module_number=3) at
/cvs/php5/ext/standard/browscap.c:169
#7 0x08088b48 in zm_startup_basic (type=1, module_number=3) at
/cvs/php5/ext/standard/basic_functions.c:1067
#8 0x0814f733 in zend_startup_module (module=0x81a5cc0) at
/cvs/php5/Zend/zend_API.c:1127
#9 0x081154c6 in php_startup_extensions (ptr=0x81ae314, count=8) at
/cvs/php5/main/main.c:1147
#10 0x0816be65 in php_startup_internal_extensions () at
main/internal_functions_cli.c:64
#11 0x0811593a in php_module_startup (sf=0x81ae280,
additional_modules=0x0, num_additional_modules=0) at
/cvs/php5/main/main.c:1311
#12 0x0816aaee in main (argc=2, argv=0xbab4) at
/cvs/php5/sapi/cli/php_cli.c:563
--
Edit this bug report at http://bugs.php.net/?id=22386&edit=1
#20278 [Opn]: .phps doesn't work since compiling PHP with Java
ID: 20278 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Slackware 8.0 PHP Version: 4.2.3 New Comment: My PHP configure string: ./configure' '--with-mysql=/usr/local/mysql' '--with-gdbm' '--with-dba' '--enable-dba=shared' '--with-db' '--enable-track-vars' '--enable-trans-sid' '--with-xml' '--with-zlib-dir=/usr' '--with-java=/usr/local/java/jdk1.2.2' '--with-apache=../apache_1.3.27 Previous Comments: [2002-11-06 05:13:42] [EMAIL PROTECTED] Built Apache 1.3.27, PHP 4.2.3 and mySQL 3.23.52, worked fine, able to view .phps files Re-built the above (from source) but with Java (J2SE 1.2.2) and now .phps files don't work. Apache httpd.conf configured correctly (AddType application/x-httpd-php-source .phps). Cheers, -- Edit this bug report at http://bugs.php.net/?id=20278&edit=1
#20278 [NEW]: .phps doesn't work since compiling PHP with Java
From: [EMAIL PROTECTED] Operating system: Slackware 8.0 PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: .phps doesn't work since compiling PHP with Java Built Apache 1.3.27, PHP 4.2.3 and mySQL 3.23.52, worked fine, able to view .phps files Re-built the above (from source) but with Java (J2SE 1.2.2) and now .phps files don't work. Apache httpd.conf configured correctly (AddType application/x-httpd-php-source .phps). Cheers, -- Edit bug report at http://bugs.php.net/?id=20278&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20278&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20278&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20278&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20278&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20278&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20278&r=support Expected behavior: http://bugs.php.net/fix.php?id=20278&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20278&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20278&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20278&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20278&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20278&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20278&r=isapi
