date:20110711

Bug #55174 [Bgs]: htmlspecialchars buggy

2011-07-11 Thread development at dayside dot net

Edit report at https://bugs.php.net/bug.php?id=55174&edit=1

 ID: 55174
 User updated by:development at dayside dot net
 Reported by:development at dayside dot net
 Summary:htmlspecialchars buggy
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   winxp sp3
 PHP Version:5.4.0alpha1
 Block user comment: N
 Private report: N

 New Comment:

correct me if i'm wrong, but this function returns nothin' in case of 'Test123'
and thats okay ? 
...and not everyone is allowed to change that php.ini setting

in some cases as a user you dont know which encoding is used... 
in such a case htmlspecialchars discards all data... thats a fantastic idea..


Previous Comments:

[2011-07-11 12:34:59] ras...@php.net

You can also set your default_charset back to iso-8859-1 in your php.ini file, 
but really these days you should be using utf-8.


[2011-07-11 10:16:10] cataphr...@php.net

The default encoding as of PHP 5.4 is UTF-8 (it was ISO-8859-1 before). 
Therefore, if your string is in ISO-8859-1, you must specify the encoding.

Closing as bogus.


[2011-07-11 07:05:33] development at dayside dot net

Description:

when any string contains any char of these -> Ã¤Ã¶Ã¼Ã 
and the string is processed with htmlspecialchars it results in an empty 
string...

Test script:
---


Actual result:
--
nothin...






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55174&edit=1

Req #52318 [Com]: Weak references for PHP

2011-07-11 Thread landeholm at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=52318&edit=1

 ID: 52318
 Comment by: landeholm at gmail dot com
 Reported by:brendel at krumedia dot de
 Summary:Weak references for PHP
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I just ran into this issue again... Please make PHP a modern language and 
implement this already.


Previous Comments:

[2010-08-09 10:17:09] brendel at krumedia dot de

bastard dot internets at gmail dot com,

for framework developers this would be very useful. It just means, when the 
user of the framework no longer use a certain object the framework also should 
not longer waste memory. There are no pitfalls for the user. But the framework 
is more flexible.


[2010-08-09 08:57:46] bastard dot internets at gmail dot com

brendel at krumedia dot de - Good call:  "$user now contains a new user object"

When looking at it from a security perspective, I do believe you just killed 
all my arguments against.  Not because you've proven it impossible, but because 
unless the developer explicitly wants that functionality, their code will have 
a thousand holes.


[2010-08-09 08:21:48] brendel at krumedia dot de

Hi bastard dot internets at gmail dot com,

see how variable references are no solution:

getUserById(1);
$repository[$user->id] = $user;

// Now two variables hold object references to one user object

$user = new User();

// $user now contains a new user object and the old one should have
// been removed from the repository. This time i do not assign null
// but another (transient) user object.
// count($repository) should equal 0.

?>


[2010-08-09 08:08:26] bastard dot internets at gmail dot com

brendel at krumedia dot de - You got me at "Also count($repository) should 
equal 0"

As I said earlier, "Registry::$Collection[$a->id] = null;" will set all 
variables referring to this object handle to null globally.  However, 
count(Registry::$Collection) is still 1.

I'd still argue this is possible using existing language features.  However, it 
means juggling so many references, forced implementing spaghetti code to get a 
solution, and a single missing "&" symbol anywhere leading to hours of 
debugging.  And, I just found myself needing just such a solution.

So, I'd have to vote for a built-in interface or class like you describe.


[2010-08-03 16:43:39] brendel at krumedia dot de

Sample code use case:

userObjectFromSomewhere();
$repository[$user->id] = $user;

// Now two variables hold object references to one user object

$user = null;

// Since $repository is weak, the destructor of the class of $user should have 
been called now
// Also count($repository) should equal 0

?>




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

https://bugs.php.net/bug.php?id=52318


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52318&edit=1

Bug->Req #55183 [Asn->Csd]: Aliasing traits

2011-07-11 Thread gron

Edit report at https://bugs.php.net/bug.php?id=55183&edit=1

 ID: 55183
 Updated by: g...@php.net
 Reported by:php at bouchery dot com
 Summary:Aliasing traits
-Status: Assigned
+Status: Closed
-Type:   Bug
+Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Windows XP
 PHP Version:5.4.0alpha1
 Assigned To:gron
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Hi:

Apologies for marking it "bogus", the bug-tracker isn't really polity.
Your use case is perfectly valid, but not supported.

The current behavior was designed this way intentionally.
We had lengthy discussions about an explicit exclude operator on the mailing 
list, and the consensus was that it is not desirable to have it, 
because it would break the consistency of a trait. (I did not follow that 
argument, since traits are not strongly consistent in anyway, but that was the 
result of the discussions.)

Thus, I am sorry, but this is not possible.

Furthermore, aliasing is NOT renaming.
As you noticed, it does not change anything, but just provides an _additional_ 
alias to the same method body.

I will close this issue, but feel free to start a discussion on the mailing 
list 
if you feel this is of greater importance.

Thanks
Stefan


Previous Comments:

[2011-07-11 16:50:52] php at bouchery dot com

Description:

I have 2 traits with the same method name. I don't want to keep one and rename 
(alias) the other, but rename both.


use X, Y {
X::set as setX;
Y::set as setY;
}

Test script:
---
_x = $x;
}
}

trait Y {
protected $_y = 0;
public function set($y) {
$this->_y = $y;
}
}

class MyClass {
use X, Y {
X::set as setX;
Y::set as setY;
}
}
?>

Expected result:

MyClass with 2 method and 2 properties : 
class MyClass
{
protected $_x = 0;
protected $_y = 0;
public function setX($x) {
$this->_x = $x;
}

public function setY($y) {
$this->_y = $y;
}
}


Actual result:
--
PHP Fatal error:  Trait method set has not been applied, because there are 
collisions with other trait methods on MyClass






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55183&edit=1

Bug #55183 [Opn->Asn]: Aliasing traits

2011-07-11 Thread felipe

Edit report at https://bugs.php.net/bug.php?id=55183&edit=1

 ID: 55183
 Updated by: fel...@php.net
 Reported by:php at bouchery dot com
 Summary:Aliasing traits
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Windows XP
 PHP Version:5.4.0alpha1
-Assigned To:
+Assigned To:gron
 Block user comment: N
 Private report: N



Previous Comments:

[2011-07-11 16:50:52] php at bouchery dot com

Description:

I have 2 traits with the same method name. I don't want to keep one and rename 
(alias) the other, but rename both.


use X, Y {
X::set as setX;
Y::set as setY;
}

Test script:
---
_x = $x;
}
}

trait Y {
protected $_y = 0;
public function set($y) {
$this->_y = $y;
}
}

class MyClass {
use X, Y {
X::set as setX;
Y::set as setY;
}
}
?>

Expected result:

MyClass with 2 method and 2 properties : 
class MyClass
{
protected $_x = 0;
protected $_y = 0;
public function setX($x) {
$this->_x = $x;
}

public function setY($y) {
$this->_y = $y;
}
}


Actual result:
--
PHP Fatal error:  Trait method set has not been applied, because there are 
collisions with other trait methods on MyClass






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55183&edit=1

Bug #55111 [Asn->Csd]: Make fails with --enable-sockets

2011-07-11 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=55111&edit=1

 ID: 55111
 Updated by: cataphr...@php.net
 Reported by:manuel at bouza dot ch
 Summary:Make fails with --enable-sockets
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OSX 10.6.7
 PHP Version:5.4SVN-2011-07-02 (SVN)
 Assigned To:cataphract
 Block user comment: N
 Private report: N



Previous Comments:

[2011-07-11 16:37:35] manuel at bouza dot ch

I tried to compile from revision 313151 and it was successful. Calling 
socket_create successfully created a socket ressource in PHP.

Seems you patch was already applied in this revision, because I got the 
following message trying to patch the file:

> sudo patch -b -i ./bug55111.diff /tmp/php-5.4-dev-
patched/ext/sockets/multicast.c
patching file /tmp/php-5.4-dev-patched/ext/sockets/multicast.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

Thanks for your help!


[2011-07-11 04:29:36] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=313126
Log: - Further fix for bug #55111 (compilation failure of ext/sockets in Mac OS 
X).


[2011-07-10 20:39:23] cataphr...@php.net

Please test this patch: http://nebm.ist.utl.pt/~glopes/misc/bug55111.diff


[2011-07-10 17:07:06] carlos dot lazcano at cursor dot cl

I have the same issue on Mac OS X snow 10.6.6.

SVN rev. 313120


./configure \
--prefix=/usr/local/php5 \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-bz2=/usr  \
--with-config-file-scan-dir=/usr/local/php5/php.d \
--with-curl \
--with-freetype-dir=/usr/local/php5 \
--with-gd \
--with-gettext \
--with-iconv-dir=/usr \
--with-imap-ssl=/usr/local \
--with-imap=/usr/local \
--with-jpeg-dir=/usr/local/php5 \
--with-kerberos=/usr \
--with-ldap \
--with-libxml-dir=shared,/usr/local/php5 \
--with-mcrypt \
--with-mhash \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-openssl=/usr \
--with-png-dir=/usr/local/php5 \
--with-snmp=/usr \
--with-t1lib=/usr/local/php5 \
--with-xmlrpc \
--with-xsl \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--enable-bcmath \
--enable-calendar \
--enable-cgi \
--enable-exif \
--enable-ftp \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-pcntl \
--enable-shmop  \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--enable-zip


[2011-07-10 16:41:58] carlos dot lazcano at cursor dot cl

I get the same error with version php5.4-201107101830

/bin/sh /Users/clazcano/Compilados/php5.4-201107101830/libtool --silent --
preserve-dup-deps --mode=compile cc  -Iext/sockets/ -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/ -DPHP_ATOM_INC -
I/Users/clazcano/Compilados/php5.4-201107101830/include -
I/Users/clazcano/Compilados/php5.4-201107101830/main -
I/Users/clazcano/Compilados/php5.4-201107101830 -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/date/lib -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/ereg/regex -
I/usr/include/libxml2 -I/usr/local/include -I/usr/local/include/freetype2 -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/oniguruma -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/libmbfl -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/libmbfl/mbfl -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/sqlite3/libsqlite -
I/opt/local/include/libxml2 -I/Users/clazcano/Compilados/php5.4-
201107101830/TSRM -I/Users/clazcano/Compilados/php5.4-201107101830/Zend  -no-
cpp-precomp  -I/usr/local/include -I/usr/local/include -L/usr/local/lib -
fvisibility=hidden -DZTS -DZEND_SIGNALS  -c /Users/clazcano/Compilados/php5.4-
201107101830/ext/sockets/multicast.c -o ext/sockets/multicast.lo 
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c: In 
function âphp_if_index_to_addr4â:
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:426: 
error: âstruct ifreqâ has no member named âifr_ifindexâ
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c: In 
function âphp_add4_to_if_indexâ:
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: âSIOCGIFINDEXâ undeclared (first use in this function)
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: (Each undeclared identifier is reported only once
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: for each function

[PHP-BUG] Bug #55183 [NEW]: Aliasing traits

2011-07-11 Thread php at bouchery dot com

From: 
Operating system: Windows XP
PHP version:  5.4.0alpha1
Package:  Class/Object related
Bug Type: Bug
Bug description:Aliasing traits

Description:

I have 2 traits with the same method name. I don't want to keep one and
rename 
(alias) the other, but rename both.


use X, Y {
X::set as setX;
Y::set as setY;
}

Test script:
---
_x = $x;
}
}

trait Y {
protected $_y = 0;
public function set($y) {
$this->_y = $y;
}
}

class MyClass {
use X, Y {
X::set as setX;
Y::set as setY;
}
}
?>

Expected result:

MyClass with 2 method and 2 properties : 
class MyClass
{
protected $_x = 0;
protected $_y = 0;
public function setX($x) {
$this->_x = $x;
}

public function setY($y) {
$this->_y = $y;
}
}


Actual result:
--
PHP Fatal error:  Trait method set has not been applied, because there are

collisions with other trait methods on MyClass

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55183&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55183&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55183&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55183&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55183&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55183&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55183&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55183&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55183&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55183&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55183&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55183&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55183&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55183&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55183&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55183&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55183&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55183&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55183&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55183&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55183&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55183&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55183&r=trysnapshot54

Bug #55111 [Fbk->Asn]: Make fails with --enable-sockets

2011-07-11 Thread manuel at bouza dot ch

Edit report at https://bugs.php.net/bug.php?id=55111&edit=1

 ID: 55111
 User updated by:manuel at bouza dot ch
 Reported by:manuel at bouza dot ch
 Summary:Make fails with --enable-sockets
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OSX 10.6.7
 PHP Version:5.4SVN-2011-07-02 (SVN)
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

I tried to compile from revision 313151 and it was successful. Calling 
socket_create successfully created a socket ressource in PHP.

Seems you patch was already applied in this revision, because I got the 
following message trying to patch the file:

> sudo patch -b -i ./bug55111.diff /tmp/php-5.4-dev-
patched/ext/sockets/multicast.c
patching file /tmp/php-5.4-dev-patched/ext/sockets/multicast.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

Thanks for your help!


Previous Comments:

[2011-07-11 04:29:36] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=313126
Log: - Further fix for bug #55111 (compilation failure of ext/sockets in Mac OS 
X).


[2011-07-10 20:39:23] cataphr...@php.net

Please test this patch: http://nebm.ist.utl.pt/~glopes/misc/bug55111.diff


[2011-07-10 17:07:06] carlos dot lazcano at cursor dot cl

I have the same issue on Mac OS X snow 10.6.6.

SVN rev. 313120


./configure \
--prefix=/usr/local/php5 \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-bz2=/usr  \
--with-config-file-scan-dir=/usr/local/php5/php.d \
--with-curl \
--with-freetype-dir=/usr/local/php5 \
--with-gd \
--with-gettext \
--with-iconv-dir=/usr \
--with-imap-ssl=/usr/local \
--with-imap=/usr/local \
--with-jpeg-dir=/usr/local/php5 \
--with-kerberos=/usr \
--with-ldap \
--with-libxml-dir=shared,/usr/local/php5 \
--with-mcrypt \
--with-mhash \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-openssl=/usr \
--with-png-dir=/usr/local/php5 \
--with-snmp=/usr \
--with-t1lib=/usr/local/php5 \
--with-xmlrpc \
--with-xsl \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--enable-bcmath \
--enable-calendar \
--enable-cgi \
--enable-exif \
--enable-ftp \
--enable-gd-native-ttf \
--enable-mbstring \
--enable-pcntl \
--enable-shmop  \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--enable-zip


[2011-07-10 16:41:58] carlos dot lazcano at cursor dot cl

I get the same error with version php5.4-201107101830

/bin/sh /Users/clazcano/Compilados/php5.4-201107101830/libtool --silent --
preserve-dup-deps --mode=compile cc  -Iext/sockets/ -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/ -DPHP_ATOM_INC -
I/Users/clazcano/Compilados/php5.4-201107101830/include -
I/Users/clazcano/Compilados/php5.4-201107101830/main -
I/Users/clazcano/Compilados/php5.4-201107101830 -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/date/lib -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/ereg/regex -
I/usr/include/libxml2 -I/usr/local/include -I/usr/local/include/freetype2 -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/oniguruma -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/libmbfl -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/mbstring/libmbfl/mbfl -
I/Users/clazcano/Compilados/php5.4-201107101830/ext/sqlite3/libsqlite -
I/opt/local/include/libxml2 -I/Users/clazcano/Compilados/php5.4-
201107101830/TSRM -I/Users/clazcano/Compilados/php5.4-201107101830/Zend  -no-
cpp-precomp  -I/usr/local/include -I/usr/local/include -L/usr/local/lib -
fvisibility=hidden -DZTS -DZEND_SIGNALS  -c /Users/clazcano/Compilados/php5.4-
201107101830/ext/sockets/multicast.c -o ext/sockets/multicast.lo 
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c: In 
function âphp_if_index_to_addr4â:
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:426: 
error: âstruct ifreqâ has no member named âifr_ifindexâ
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c: In 
function âphp_add4_to_if_indexâ:
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: âSIOCGIFINDEXâ undeclared (first use in this function)
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: (Each undeclared identifier is reported only once
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:506: 
error: for each function it appears in.)
/Users/clazcano/Compilados/php5.4-201107101830/ext/sockets/multicast.c:513: 
error

[PHP-BUG] Bug #55182 [NEW]: finfo_file() doesn't detect right mime-type

2011-07-11 Thread dominique at ramaekers-stassart dot be

From: 
Operating system: Ubuntu 10.04
PHP version:  5.3SVN-2011-07-11 (SVN)
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:finfo_file() doesn't detect right mime-type

Description:

The finfo_file command detects openxml documents (xlsb, xlsx,...) as
application/zip files.

Can this be fixed?

There are a lot of people who have to hack the mediawiki code to allow
these files for upload. With these hacks they lose a part of there
security: the checking of the finfo_file-mime-type against the file
extension itself...


Test script:
---
php > $finfo = finfo_open(FILEINFO_MIME_TYPE);
php > echo finfo_file($finfo, '/mnt/Transfert/test.xlsb');
application/zip





-- 
Edit bug report at https://bugs.php.net/bug.php?id=55182&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55182&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55182&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55182&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55182&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55182&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55182&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55182&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55182&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55182&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55182&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55182&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55182&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55182&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55182&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55182&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55182&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55182&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55182&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55182&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55182&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55182&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55182&r=trysnapshot54

Bug #55169 [Csd->Asn]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread pajoye

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 Updated by: paj...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
-Status: Closed
+Status: Assigned
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

just assigning it to me, needs some more testing under apache and IIS, Seldaek 
is 
still having this problem


Previous Comments:

[2011-07-11 14:20:08] ni...@php.net

Okay, closing it again then ;)


[2011-07-11 12:50:43] ahar...@php.net

I did. Sorry, misread the bug. The lesson is that I need to do one thing at 
once, 
rather than ten. :)


[2011-07-11 12:41:04] paj...@php.net

No idea, who made that change?


[2011-07-11 11:08:47] ni...@php.net

Why is this Bogus now?


[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Bug #55169 [Opn->Csd]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread ni...@php.net

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 User updated by:ni...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
-Status: Open
+Status: Closed
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Okay, closing it again then ;)


Previous Comments:

[2011-07-11 12:50:43] ahar...@php.net

I did. Sorry, misread the bug. The lesson is that I need to do one thing at 
once, 
rather than ten. :)


[2011-07-11 12:41:04] paj...@php.net

No idea, who made that change?


[2011-07-11 11:08:47] ni...@php.net

Why is this Bogus now?


[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.


[2011-07-10 17:38:39] ni...@php.net

Hm, seems like I indeed used some wrong binary. I have just downloaded 313114ts 
again and it worked :)

Thanks for the quick fix and sorry for the confusion ^^

Closing this then ;)




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Bug #34849 [Com]: array_key_exists and isset misbehavior with ArrayAccess

2011-07-11 Thread jon at phpsitesolutions dot com

Edit report at https://bugs.php.net/bug.php?id=34849&edit=1

 ID: 34849
 Comment by: jon at phpsitesolutions dot com
 Reported by:tschundler at gmail dot com
 Summary:array_key_exists and isset misbehavior with
 ArrayAccess
 Status: Bogus
 Type:   Bug
 Package:Arrays related
 Operating System:   *
 PHP Version:5.*
 Block user comment: N
 Private report: N

 New Comment:

BTW, that tidbit (array_* functions are not compatible with ArrayAccess) is not 
mentioned in the manual, which makes it pointless to point the bug reporter to 
the manual.

And no, I'm not submitting a bug request for that change to be added, as I'm 
not 
the person that:
- pointed the reporter back to the manual
- noted that array_* functions are incompatible

Seems the bug request should be on that person in that case.


Previous Comments:

[2011-07-11 14:17:11] jon at phpsitesolutions dot com

That's ridiculous, that ArrayAccess doesn't work with PHP's own array_* 
functions.
If that's the case, why provide ArrayAccess as an SPL class?
You'd think that SPL classes would have full functionality with native PHP, yet 
because someone was apparently lazy during implementation, it doesn't.

And so of course, 6 years later, this is still an issue that has not been 
rectified.

Now I see why PHP has such a bad reputation when compared against other quality 
languages...


[2005-10-13 08:24:01] he...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

ArrayAccess objects don't work in array_*() functions. You may want to turn 
this report into a feature request?


[2005-10-13 06:56:36] tschundler at gmail dot com

Description:

Functions to test an array's content don't work consistently with ArrayAccess 
objects.

In the example, the object will return TRUE a request for any key. But, 
array_key_exists always returns FALSE, seemingly testing nothing, when it 
should be using the offsetExists method.

Additionally, isset() on an array will return FALSE if the value at that offset 
is NULL. But with an ArrayAccess object, it returns TRUE, using the 
offsetExists method.

Reproduce code:
---
class ArrayTest implements ArrayAccess {
function offsetExists ($offset) {return TRUE;}
function offsetGet ($offset) {return ($offset==0) ? NULL : $offset;}
function offsetSet ($offset, $value) {}
function offsetUnset ($offset) {}
}

echo "with ArrayAcces:\n";
$x=new ArrayTest();
var_dump(array_key_exists(0,$x));
var_dump(array_key_exists(1,$x));
var_dump(isset($x[0]));
var_dump(isset($x[1]));

echo "with array():\n";
$y=array(0=>NULL,1=>1);
var_dump(array_key_exists(0,$y));
var_dump(array_key_exists(1,$y)); 
var_dump(isset($y[0]));
var_dump(isset($y[1]));


Expected result:

with ArrayAcces:
bool(true)
bool(true)
bool(false)
bool(true)
with array():
bool(true)
bool(true)
bool(false)
bool(true)


Actual result:
--
with ArrayAcces:
bool(false)
bool(false)
bool(true)
bool(true)
with array():
bool(true)
bool(true)
bool(false)
bool(true)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=34849&edit=1

Bug #34849 [Com]: array_key_exists and isset misbehavior with ArrayAccess

2011-07-11 Thread jon at phpsitesolutions dot com

Edit report at https://bugs.php.net/bug.php?id=34849&edit=1

 ID: 34849
 Comment by: jon at phpsitesolutions dot com
 Reported by:tschundler at gmail dot com
 Summary:array_key_exists and isset misbehavior with
 ArrayAccess
 Status: Bogus
 Type:   Bug
 Package:Arrays related
 Operating System:   *
 PHP Version:5.*
 Block user comment: N
 Private report: N

 New Comment:

That's ridiculous, that ArrayAccess doesn't work with PHP's own array_* 
functions.
If that's the case, why provide ArrayAccess as an SPL class?
You'd think that SPL classes would have full functionality with native PHP, yet 
because someone was apparently lazy during implementation, it doesn't.

And so of course, 6 years later, this is still an issue that has not been 
rectified.

Now I see why PHP has such a bad reputation when compared against other quality 
languages...


Previous Comments:

[2005-10-13 08:24:01] he...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

ArrayAccess objects don't work in array_*() functions. You may want to turn 
this report into a feature request?


[2005-10-13 06:56:36] tschundler at gmail dot com

Description:

Functions to test an array's content don't work consistently with ArrayAccess 
objects.

In the example, the object will return TRUE a request for any key. But, 
array_key_exists always returns FALSE, seemingly testing nothing, when it 
should be using the offsetExists method.

Additionally, isset() on an array will return FALSE if the value at that offset 
is NULL. But with an ArrayAccess object, it returns TRUE, using the 
offsetExists method.

Reproduce code:
---
class ArrayTest implements ArrayAccess {
function offsetExists ($offset) {return TRUE;}
function offsetGet ($offset) {return ($offset==0) ? NULL : $offset;}
function offsetSet ($offset, $value) {}
function offsetUnset ($offset) {}
}

echo "with ArrayAcces:\n";
$x=new ArrayTest();
var_dump(array_key_exists(0,$x));
var_dump(array_key_exists(1,$x));
var_dump(isset($x[0]));
var_dump(isset($x[1]));

echo "with array():\n";
$y=array(0=>NULL,1=>1);
var_dump(array_key_exists(0,$y));
var_dump(array_key_exists(1,$y)); 
var_dump(isset($y[0]));
var_dump(isset($y[1]));


Expected result:

with ArrayAcces:
bool(true)
bool(true)
bool(false)
bool(true)
with array():
bool(true)
bool(true)
bool(false)
bool(true)


Actual result:
--
with ArrayAcces:
bool(false)
bool(false)
bool(true)
bool(true)
with array():
bool(true)
bool(true)
bool(false)
bool(true)







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=34849&edit=1

Bug #55014 [Opn->Csd]: Error Compiling: too many arguments to function `ctime_r'

2011-07-11 Thread iliaa

Edit report at https://bugs.php.net/bug.php?id=55014&edit=1

 ID: 55014
 Updated by: il...@php.net
 Reported by:rosnerb at htw-berlin dot de
 Summary:Error Compiling: too many arguments to function
 `ctime_r'
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Solaris 10
 PHP Version:5.3.6
-Assigned To:
+Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-07-11 13:01:21] il...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=313144
Log: Fixed bug #55014 (Compile failure due to improper use of ctime_r()).


[2011-06-09 14:01:17] rosnerb at htw-berlin dot de

Description:

/prog/src/php-5.3.6/main/reentrancy.c: In function `php_ctime_r':
/prog/src/php-5.3.6/main/reentrancy.c:63: error: too many arguments to function 
`ctime_r'
/prog/src/php-5.3.6/main/reentrancy.c: In function `php_asctime_r':
/prog/src/php-5.3.6/main/reentrancy.c:70: error: too many arguments to function 
`asctime_r'
gmake: *** [main/reentrancy.lo] Error 1

Using gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) on SunOS 5.10 i386 
with CFLAGS=-O3 -m64
Following configure options were used, also --disable-all did produce the 
error. Configure went through without problems. 

./configure --prefix=/prog/apps/php-5.3.6 \
--with-config-file-path=/prog/etc/php \
--sysconfdir=/prog/etc/php \
--with-apxs2=/prog/apps/apache-2.2.18/bin/apxs \
--with-ldap=/prog/apps/openldap-2.4.23 \
--with-openssl=/prog/apps/openssl-1.0.0d \
--with-mysql=/prog/apps/mysql-5.5.12 \
--with-mysqli \
--with-pear \
--with-gettext=/prog/apps/gettext \
--with-jpeg-dir=/prog/apps/jpeg-8c \
--with-png-dir=/prog/apps/libpng-1.5.2 \
--with-zlib=/prog/apps/zlib \
--with-zlib-dir=/prog/apps/zlib \
--with-libxml-dir=/prog/apps/libxml2 \
--with-iconv=/prog/apps/libiconv \
--with-gd=/prog/apps/gd \
--with-mcrypt=/prog/apps/libmcrypt \
--with-imap=/prog/apps/imap-2007e \
--with-imap-ssl=/prog/apps/openssl-1.0.0a \
--with-curl=/prog/apps/curl-7.21.6 \
--with-curlwrappers \
--with-pgsql \
--with-pgsql=/usr/postgres/8.3 \
--enable-ftp \
--with-regex=php \
--enable-zip \
--enable-mbstring \
--enable-ctype \
--enable-sysvshm \
--enable-calendar \
--enable-exif \
--enable-gd-native-ttf \
--enable-sockets \
--enable-safe-mode

Removing third argument '26' of ctime_r() and asctime_r() in line 63 and 70 
fixes this error.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55014&edit=1

Bug #55171 [Opn->Bgs]: XML tags are meant to be case sensitive - but PHP displays them in all caps

2011-07-11 Thread iliaa

Bug #55168 [Opn->Csd]: mcrypt_create_iv uses E_ERROR on Win and E_WARNING on *nix

2011-07-11 Thread iliaa

Edit report at https://bugs.php.net/bug.php?id=55168&edit=1

 ID: 55168
 Updated by: il...@php.net
 Reported by:ircmaxell at gmail dot com
 Summary:mcrypt_create_iv uses E_ERROR on Win and E_WARNING
 on *nix
-Status: Open
+Status: Closed
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows
 PHP Version:5.4SVN-2011-07-09 (SVN)
-Assigned To:
+Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-07-09 15:33:00] ircmaxell at gmail dot com

Description:

If you call mcrypt_create_iv with either the MCRYPT_DEV_RANDOM or 
MCRYPT_DEV_URANDOM constants, and it cannot generate enough data, it issues an 
E_ERROR fatal error.  However, on linux when the same situation it will just 
issue 
an E_WARNING.

I suggest that it should be changed from an E_ERROR to an E_WARNING on Windows 
(as 
it certainly is recoverable).

See:

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mcrypt/mcrypt.c?
revision=311033&view=markup

Specifically lines 1397 and 1422







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55168&edit=1

Bug #55169 [Opn]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread aharvey

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 Updated by: ahar...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
 Status: Open
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I did. Sorry, misread the bug. The lesson is that I need to do one thing at 
once, 
rather than ten. :)


Previous Comments:

[2011-07-11 12:41:04] paj...@php.net

No idea, who made that change?


[2011-07-11 11:08:47] ni...@php.net

Why is this Bogus now?


[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.


[2011-07-10 17:38:39] ni...@php.net

Hm, seems like I indeed used some wrong binary. I have just downloaded 313114ts 
again and it worked :)

Thanks for the quick fix and sorry for the confusion ^^

Closing this then ;)


[2011-07-10 16:58:13] paj...@php.net

I can't reproduce the problem, are you sure you used the right binaries?


c:\test\php540r313114>php -d extension_dir=ext -d extension=php_openssl.dll -r 
"var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "âº"

and using NTS:

c:\test\php540ntsr313114>php -d extension_dir=ext -d extension=php_openssl.dll -
r "var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "â"




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Bug #55169 [Bgs->Opn]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread pajoye

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 Updated by: paj...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
-Status: Bogus
+Status: Open
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
 Block user comment: N
 Private report: N

 New Comment:

No idea, who made that change?


Previous Comments:

[2011-07-11 11:08:47] ni...@php.net

Why is this Bogus now?


[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.


[2011-07-10 17:38:39] ni...@php.net

Hm, seems like I indeed used some wrong binary. I have just downloaded 313114ts 
again and it worked :)

Thanks for the quick fix and sorry for the confusion ^^

Closing this then ;)


[2011-07-10 16:58:13] paj...@php.net

I can't reproduce the problem, are you sure you used the right binaries?


c:\test\php540r313114>php -d extension_dir=ext -d extension=php_openssl.dll -r 
"var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "âº"

and using NTS:

c:\test\php540ntsr313114>php -d extension_dir=ext -d extension=php_openssl.dll -
r "var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "â"


[2011-07-10 14:53:33] ni...@php.net

I just tried using an nts instead of a ts build, and it worked there. So it's 
seems to be some thread safety related problem.




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Bug #55174 [Bgs]: htmlspecialchars buggy

2011-07-11 Thread rasmus

Edit report at https://bugs.php.net/bug.php?id=55174&edit=1

 ID: 55174
 Updated by: ras...@php.net
 Reported by:development at dayside dot net
 Summary:htmlspecialchars buggy
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   winxp sp3
 PHP Version:5.4.0alpha1
 Block user comment: N
 Private report: N

 New Comment:

You can also set your default_charset back to iso-8859-1 in your php.ini file, 
but really these days you should be using utf-8.


Previous Comments:

[2011-07-11 10:16:10] cataphr...@php.net

The default encoding as of PHP 5.4 is UTF-8 (it was ISO-8859-1 before). 
Therefore, if your string is in ISO-8859-1, you must specify the encoding.

Closing as bogus.


[2011-07-11 07:05:33] development at dayside dot net

Description:

when any string contains any char of these -> Ã¤Ã¶Ã¼Ã 
and the string is processed with htmlspecialchars it results in an empty 
string...

Test script:
---


Actual result:
--
nothin...






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55174&edit=1

Req #36261 [Com]: similar_text parameters aren't convertible

2011-07-11 Thread dejaschinski at googlemail dot com

Edit report at https://bugs.php.net/bug.php?id=36261&edit=1

 ID: 36261
 Comment by: dejaschinski at googlemail dot com
 Reported by:mac30 at narod dot ru
 Summary:similar_text parameters aren't convertible
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   linux - kernel 2.6
 PHP Version:4.4.2
 Block user comment: N
 Private report: N

 New Comment:

I've running in the same problem. I'm using php-5.3.6 with opensuse11.3.

https://bugs.php.net/bug.php?id=36261&edit=1

Bug #55180 [Opn->Bgs]: substr return is fail

2011-07-11 Thread aharvey

Edit report at https://bugs.php.net/bug.php?id=55180&edit=1

 ID: 55180
 Updated by: ahar...@php.net
 Reported by:jonasvdegn at hotmail dot com
 Summary:substr return is fail
-Status: Open
+Status: Bogus
 Type:   Bug
-Package:Output Control
+Package:Strings related
 Operating System:   Windows 7
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

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.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The third parameter for substr() is the number of characters to return, not the 
end position.


Previous Comments:

[2011-07-11 07:52:45] jonasvdegn at hotmail dot com

Description:

the substr(string,from,to) failed and return something i find strange, and 
never seen it before..

my version is also 5.3.5 but i chose 5.3.6 because the 5.3.5 is not there.

Test script:
---
$x=1;
while ($x<=strlen("hello"))
{
$xx=$x-1;
echo substr("hello",$xx,$x);
$x++;
}
echo "";

$x=1;
while ($x<=strlen("hello"))
{
$xx=$x-1;
echo $xx." ";
echo $x." ";
echo substr("hello",$xx,$x);
echo "";
$x++;
}

Expected result:

i expect a result saying:

hello
0 1 h
1 2 e
2 3 l
3 4 l
4 5 o

like in substr("hello",0,1) substr("hello",1,2) and continue like that.

Actual result:
--
the actual result is:

hellloloo
0 1 h
1 2 el
2 3 llo
3 4 lo
4 5 o

like substr("hello",1,2) is "el" how can that be?
and  substr("hello",2,3) is "llo" and how can that be too?






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55180&edit=1

Req #54037 [Opn->Tbd]: [PATCH] Adds the ability to pass options to loadHTML

2011-07-11 Thread chregu

Edit report at https://bugs.php.net/bug.php?id=54037&edit=1

 ID: 54037
 Updated by: chr...@php.net
 Reported by:fxmulder at gmail dot com
 Summary:[PATCH] Adds the ability to pass options to loadHTML
-Status: Open
+Status: To be documented
 Type:   Feature/Change Request
 Package:DOM XML related
 PHP Version:trunk-SVN-2011-02-17 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Committed to trunk and PHP_5_4 branch


Previous Comments:

[2011-03-29 22:27:40] fxmulder at gmail dot com

That works for me, this still good to be committed to the trunk?


[2011-03-03 08:12:00] chr...@php.net

The following patch has been added/updated:

Patch Name: patch-for-adding-loadhtml-options.patch
Revision:   1299136320
URL:
http://bugs.php.net/patch-display.php?bug=54037&patch=patch-for-adding-loadhtml-options.patch&revision=1299136320


[2011-03-03 08:11:04] chr...@php.net

After talking with Rob, we removed LIBXML_RECOVER again. People don't like 
seeing 
that wildly used, there were and are always a lot of discussions, if that's a 
good 
thing at all. So we just remove the constant again for now.

I'll attach the new patch. If noone complains, I will commit it soon


[2011-02-22 17:11:08] chr...@php.net

Looks fine to me, Will commit soon to trunk


[2011-02-18 00:21:20] fxmulder at gmail dot com

I've also included a patch to create new constants for use as options




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

https://bugs.php.net/bug.php?id=54037


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54037&edit=1

Bug #55169 [Com]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread ni...@php.net

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 Comment by: ni...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
 Status: Bogus
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Why is this Bogus now?


Previous Comments:

[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.


[2011-07-10 17:38:39] ni...@php.net

Hm, seems like I indeed used some wrong binary. I have just downloaded 313114ts 
again and it worked :)

Thanks for the quick fix and sorry for the confusion ^^

Closing this then ;)


[2011-07-10 16:58:13] paj...@php.net

I can't reproduce the problem, are you sure you used the right binaries?


c:\test\php540r313114>php -d extension_dir=ext -d extension=php_openssl.dll -r 
"var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "âº"

and using NTS:

c:\test\php540ntsr313114>php -d extension_dir=ext -d extension=php_openssl.dll -
r "var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "â"


[2011-07-10 14:53:33] ni...@php.net

I just tried using an nts instead of a ts build, and it worked there. So it's 
seems to be some thread safety related problem.


[2011-07-10 14:32:12] ni...@php.net

I'm still seeing the issue in 313114:

D:\htdocs\stack>C:\php313114\php.exe -f quick.php

Warning: mcrypt_create_iv(): Could not gather sufficient random data in D:\htdoc
s\stack\quick.php on line 3
bool(false)




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Bug #55169 [Csd->Bgs]: mcrypt_create_iv always fails to gather sufficient random data

2011-07-11 Thread aharvey

Edit report at https://bugs.php.net/bug.php?id=55169&edit=1

 ID: 55169
 Updated by: ahar...@php.net
 Reported by:ni...@php.net
 Summary:mcrypt_create_iv always fails to gather sufficient
 random data
-Status: Closed
+Status: Bogus
 Type:   Bug
 Package:mcrypt related
 Operating System:   Windows 7
 PHP Version:5.4SVN-2011-07-09 (snap)
-Assigned To:pajoye
+Assigned To:
 Block user comment: N
 Private report: N



Previous Comments:

[2011-07-10 17:41:17] ni...@php.net

Argh, I just can't handle this bugtracker :( Seems like it assignes the bug to 
me if I leave the "Assign to" field empty.


[2011-07-10 17:38:39] ni...@php.net

Hm, seems like I indeed used some wrong binary. I have just downloaded 313114ts 
again and it worked :)

Thanks for the quick fix and sorry for the confusion ^^

Closing this then ;)


[2011-07-10 16:58:13] paj...@php.net

I can't reproduce the problem, are you sure you used the right binaries?


c:\test\php540r313114>php -d extension_dir=ext -d extension=php_openssl.dll -r 
"var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "âº"

and using NTS:

c:\test\php540ntsr313114>php -d extension_dir=ext -d extension=php_openssl.dll -
r "var_dump(mcrypt_create_iv(1, MCRYPT_DEV_URANDOM));"
string(1) "â"


[2011-07-10 14:53:33] ni...@php.net

I just tried using an nts instead of a ts build, and it worked there. So it's 
seems to be some thread safety related problem.


[2011-07-10 14:32:12] ni...@php.net

I'm still seeing the issue in 313114:

D:\htdocs\stack>C:\php313114\php.exe -f quick.php

Warning: mcrypt_create_iv(): Could not gather sufficient random data in D:\htdoc
s\stack\quick.php on line 3
bool(false)




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

https://bugs.php.net/bug.php?id=55169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55169&edit=1

Req #55181 [PATCH]: Enhance security by limiting the script extension

2011-07-11 Thread f...@php.net

Edit report at https://bugs.php.net/bug.php?id=55181&edit=1

 ID: 55181
 Patch added by: f...@php.net
 Reported by:f...@php.net
 Summary:Enhance security by limiting the script extension
 Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   any
 PHP Version:5.3.6
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: fpm-extensions.v2.patch
Revision:   1310393984
URL:
https://bugs.php.net/patch-display.php?bug=55181&patch=fpm-extensions.v2.patch&revision=1310393984


Previous Comments:

[2011-07-11 08:36:13] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-extensions.v1.patch
Revision:   1310387773
URL:
https://bugs.php.net/patch-display.php?bug=55181&patch=fpm-extensions.v1.patch&revision=1310387773


[2011-07-11 08:29:37] f...@php.net

Description:

If the web server in front of FPM is misconfigured, FPM can parse and execute 
PHP 
code from any kind of files (test.php, test.txt, test.jpg, test.css, ...).

It should be possible to limit the extension of the primary script FPM will 
execute.

Something like (in pool configuration)
security.limit_extensions = .php

if the primary script does not end with .php, an access denied is returned 
(403).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55181&edit=1

Bug #55174 [Opn->Bgs]: htmlspecialchars buggy

2011-07-11 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=55174&edit=1

 ID: 55174
 Updated by: cataphr...@php.net
 Reported by:development at dayside dot net
 Summary:htmlspecialchars buggy
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   winxp sp3
 PHP Version:5.4.0alpha1
 Block user comment: N
 Private report: N

 New Comment:

The default encoding as of PHP 5.4 is UTF-8 (it was ISO-8859-1 before). 
Therefore, if your string is in ISO-8859-1, you must specify the encoding.

Closing as bogus.


Previous Comments:

[2011-07-11 07:05:33] development at dayside dot net

Description:

when any string contains any char of these -> Ã¤Ã¶Ã¼Ã 
and the string is processed with htmlspecialchars it results in an empty 
string...

Test script:
---


Actual result:
--
nothin...






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55174&edit=1

Req #55181 [PATCH]: Enhance security by limiting the script extension

2011-07-11 Thread f...@php.net

Edit report at https://bugs.php.net/bug.php?id=55181&edit=1

 ID: 55181
 Patch added by: f...@php.net
 Reported by:f...@php.net
 Summary:Enhance security by limiting the script extension
 Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   any
 PHP Version:5.3.6
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: fpm-extensions.v1.patch
Revision:   1310387773
URL:
https://bugs.php.net/patch-display.php?bug=55181&patch=fpm-extensions.v1.patch&revision=1310387773


Previous Comments:

[2011-07-11 08:29:37] f...@php.net

Description:

If the web server in front of FPM is misconfigured, FPM can parse and execute 
PHP 
code from any kind of files (test.php, test.txt, test.jpg, test.css, ...).

It should be possible to limit the extension of the primary script FPM will 
execute.

Something like (in pool configuration)
security.limit_extensions = .php

if the primary script does not end with .php, an access denied is returned 
(403).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55181&edit=1

Req #55181 [Opn->Ana]: Enhance security by limiting the script extension

2011-07-11 Thread fat

Edit report at https://bugs.php.net/bug.php?id=55181&edit=1

 ID: 55181
 Updated by: f...@php.net
 Reported by:f...@php.net
 Summary:Enhance security by limiting the script extension
-Status: Open
+Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   any
 PHP Version:5.3.6
-Assigned To:
+Assigned To:fat
 Block user comment: N
 Private report: N



Previous Comments:

[2011-07-11 08:29:37] f...@php.net

Description:

If the web server in front of FPM is misconfigured, FPM can parse and execute 
PHP 
code from any kind of files (test.php, test.txt, test.jpg, test.css, ...).

It should be possible to limit the extension of the primary script FPM will 
execute.

Something like (in pool configuration)
security.limit_extensions = .php

if the primary script does not end with .php, an access denied is returned 
(403).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55181&edit=1

[PHP-BUG] Req #55181 [NEW]: Enhance security by limiting the script extension

2011-07-11 Thread f...@php.net

From: fat
Operating system: any
PHP version:  5.3.6
Package:  FPM related
Bug Type: Feature/Change Request
Bug description:Enhance security by limiting the script extension

Description:

If the web server in front of FPM is misconfigured, FPM can parse and
execute PHP 
code from any kind of files (test.php, test.txt, test.jpg, test.css, ...).

It should be possible to limit the extension of the primary script FPM will

execute.

Something like (in pool configuration)
security.limit_extensions = .php

if the primary script does not end with .php, an access denied is returned
(403).


-- 
Edit bug report at https://bugs.php.net/bug.php?id=55181&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55181&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55181&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55181&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55181&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55181&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55181&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55181&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55181&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55181&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55181&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55181&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55181&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55181&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55181&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55181&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55181&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55181&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55181&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55181&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55181&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55181&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55181&r=trysnapshot54

[PHP-BUG] Bug #55180 [NEW]: substr return is fail

2011-07-11 Thread jonasvdegn at hotmail dot com

From: 
Operating system: Windows 7
PHP version:  5.3.6
Package:  Output Control
Bug Type: Bug
Bug description:substr return is fail

Description:

the substr(string,from,to) failed and return something i find strange, and
never seen it before..

my version is also 5.3.5 but i chose 5.3.6 because the 5.3.5 is not there.

Test script:
---
$x=1;
while ($x<=strlen("hello"))
{
$xx=$x-1;
echo substr("hello",$xx,$x);
$x++;
}
echo "";

$x=1;
while ($x<=strlen("hello"))
{
$xx=$x-1;
echo $xx." ";
echo $x." ";
echo substr("hello",$xx,$x);
echo "";
$x++;
}

Expected result:

i expect a result saying:

hello
0 1 h
1 2 e
2 3 l
3 4 l
4 5 o

like in substr("hello",0,1) substr("hello",1,2) and continue like that.

Actual result:
--
the actual result is:

hellloloo
0 1 h
1 2 el
2 3 llo
3 4 lo
4 5 o

like substr("hello",1,2) is "el" how can that be?
and  substr("hello",2,3) is "llo" and how can that be too?

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55180&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55180&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55180&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55180&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55180&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55180&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55180&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55180&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55180&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55180&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55180&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55180&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55180&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55180&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55180&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55180&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55180&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55180&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55180&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55180&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55180&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55180&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55180&r=trysnapshot54

[PHP-BUG] Req #55179 [NEW]: Offer preg_match with array-support for pattern

2011-07-11 Thread neufe...@php.net

From: neufeind
Operating system: 
PHP version:  5.3.6
Package:  PCRE related
Bug Type: Feature/Change Request
Bug description:Offer preg_match with array-support for pattern

Description:

Maybe the existing preg_match could allow for an array to be given as
$pattern. Or if not a preg_match_array() might be an alternative.

Idea is to check a string against a list of pattern. First matched pattern
would return.

Test script:
---
https://bugs.php.net/bug.php?id=55179&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55179&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55179&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55179&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55179&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55179&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55179&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55179&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55179&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55179&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55179&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55179&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55179&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55179&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55179&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55179&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55179&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55179&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55179&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55179&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55179&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55179&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55179&r=trysnapshot54

Bug #55175 [Opn]: SplFileInfo throws a LogicException saying it's constructor has to be called

2011-07-11 Thread salathe

Edit report at https://bugs.php.net/bug.php?id=55175&edit=1

 ID: 55175
 Updated by: sala...@php.net
 Reported by:s...@php.net
 Summary:SplFileInfo throws a LogicException saying it's
 constructor has to be called
 Status: Open
 Type:   Bug
 Package:SPL related
-Operating System:   Windows 7, x64
+Operating System:   
 PHP Version:5.4SVN-2011-07-11 (snap)
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Related to #54384


Previous Comments:

[2011-07-11 07:09:04] s...@php.net

Description:

SplFileInfo throws the following exception whenever you extend it:

LogicException: In the constructor of ExtendingClass, parent::__construct() 
must be called and its exceptions cannot be cleared

Note that, in the example below, defining the constructor explicitly and 
calling parent::__construct() does not fix the issue.

Test script:
---
# php -r 'class Foo extends SplFileInfo {} new SplFileInfo("foo"); new Foo("bar
");'


Expected result:

No output

Actual result:
--
Fatal error: Uncaught exception 'LogicException' with message 'In the 
constructor of Foo, parent::__construct() must be called and its exceptions 
cannot be cleared' in Command line code:1
Stack trace:
#0 Command line code(1): Foo->internal_construction_wrapper('bar')
#1 {main}
  thrown in Command line code on line 1






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55175&edit=1

[PHP-BUG] Bug #55175 [NEW]: SplFileInfo throws a LogicException saying it's constructor has to be called

2011-07-11 Thread s...@php.net

From: seld
Operating system: Windows 7, x64
PHP version:  5.4SVN-2011-07-11 (snap)
Package:  SPL related
Bug Type: Bug
Bug description:SplFileInfo throws a LogicException saying it's constructor has 
to be called

Description:

SplFileInfo throws the following exception whenever you extend it:

LogicException: In the constructor of ExtendingClass, parent::__construct()
must be called and its exceptions cannot be cleared

Note that, in the example below, defining the constructor explicitly and
calling parent::__construct() does not fix the issue.

Test script:
---
# php -r 'class Foo extends SplFileInfo {} new SplFileInfo("foo"); new
Foo("bar
");'


Expected result:

No output

Actual result:
--
Fatal error: Uncaught exception 'LogicException' with message 'In the
constructor of Foo, parent::__construct() must be called and its exceptions
cannot be cleared' in Command line code:1
Stack trace:
#0 Command line code(1): Foo->internal_construction_wrapper('bar')
#1 {main}
  thrown in Command line code on line 1

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55175&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55175&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55175&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55175&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55175&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55175&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55175&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55175&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55175&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55175&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55175&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55175&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55175&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55175&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55175&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55175&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55175&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55175&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55175&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55175&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55175&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55175&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55175&r=trysnapshot54

[PHP-BUG] Bug #55174 [NEW]: htmlspecialchars buggy

2011-07-11 Thread development at dayside dot net

From: 
Operating system: winxp sp3
PHP version:  5.4.0alpha1
Package:  *General Issues
Bug Type: Bug
Bug description:htmlspecialchars buggy

Description:

when any string contains any char of these -> Ã¤Ã¶Ã¼Ã 
and the string is processed with htmlspecialchars it results in an empty
string...

Test script:
---


Actual result:
--
nothin...

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55174&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55174&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55174&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55174&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55174&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55174&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55174&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55174&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55174&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55174&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55174&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55174&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55174&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55174&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55174&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55174&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55174&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55174&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55174&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55174&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55174&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55174&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55174&r=trysnapshot54

Bug #55173 [Opn]: Locale::setDefault never failed

2011-07-11 Thread jinmoku at hotmail dot com

Edit report at https://bugs.php.net/bug.php?id=55173&edit=1

 ID: 55173
 User updated by:jinmoku at hotmail dot com
 Reported by:jinmoku at hotmail dot com
 Summary:Locale::setDefault never failed
 Status: Open
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   Win 7
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

you don't use uloc_setDefault  ???


Previous Comments:

[2011-07-11 05:03:51] jinmoku at hotmail dot com

Description:

Locale::setDefault never failed even with wrong value

Test script:
---
var_dump(Locale::setDefault(''));
var_dump(Locale::setDefault(null));
var_dump(Locale::setDefault(false));
var_dump(Locale::setDefault(true));
var_dump(Locale::setDefault('en_US'));

Expected result:

bool(false)
bool(false)
bool(false)
bool(false)
bool(true)

Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55173&edit=1

[PHP-BUG] Bug #55173 [NEW]: Locale::setDefault never failed

2011-07-11 Thread jinmoku at hotmail dot com

From: 
Operating system: Win 7
PHP version:  5.3.6
Package:  I18N and L10N related
Bug Type: Bug
Bug description:Locale::setDefault never failed

Description:

Locale::setDefault never failed even with wrong value

Test script:
---
var_dump(Locale::setDefault(''));
var_dump(Locale::setDefault(null));
var_dump(Locale::setDefault(false));
var_dump(Locale::setDefault(true));
var_dump(Locale::setDefault('en_US'));

Expected result:

bool(false)
bool(false)
bool(false)
bool(false)
bool(true)

Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55173&edit=1
-- 
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55173&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55173&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55173&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55173&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55173&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55173&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55173&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55173&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55173&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55173&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55173&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55173&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55173&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55173&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55173&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55173&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55173&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55173&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55173&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55173&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55173&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55173&r=trysnapshot54

Req #52569 [Com]: Implement "ondemand" process-manager (to allow zero children)

2011-07-11 Thread f...@php.net

Edit report at https://bugs.php.net/bug.php?id=52569&edit=1

 ID: 52569
 Comment by: f...@php.net
 Reported by:mplomer at gmx dot de
 Summary:Implement "ondemand" process-manager (to allow zero
 children)
 Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 PHP Version:5.3.3
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

As 5.3.7 is in a RC release process, only bugfixes are going there until 5.3.7 
is 
out.

so the ondemand will be added in 5.3.7+ and 5.4 and marked as experimental.


Previous Comments:

[2011-07-11 02:36:28] dbetz at df dot eu

Hello all,

now all works fine for me. Great work !! +1
I hope this gets implemented in 5.3.7 stable release :-)

Im testing on an Gentoo 1.12.13

Greetings,
Daniel


[2011-07-10 18:20:12] trollofdarkness at gmail dot com

Ok, thanks for the information :) 

-- Troll


[2011-07-10 18:03:29] f...@php.net

glad to hear.

The slowest your server is the highest you should set events.delay.

In fact 1 or 2 ms (1000 or 2000 for events.delay value) should be considered as 
a 
maximum in order not to slow down too much requests.


[2011-07-10 17:38:06] trollofdarkness at gmail dot com

Ok so I finally found why there was two requests using a browser.

There was a .js file loaded in the page, which was generated by a php script.

So the browser loading in parallel HTML and JS files, there was two 
simultaneous requests to PHP.

So the conclusion is events.delays >= 1200 for me to work.

If it could help, here's my server characteristics : NANO VIA U2250 // Debian 
Lenny 64bits // 2GB RAM // 160G SATA2


[2011-07-10 16:40:30] trollofdarkness at gmail dot com

Ok so I got it working.

When using a simple curl request, I have to put events.delay = 1200 (minimum) 
to get only 1fork/req

When using a browser... I have to put events.delay = 4000 or 5000 (I can't 
remember which one was working, neither the first or the second, but I don't 
think, arrived at such a value, that it changes anything) but maybe Opera & 
Firefox (tested with the two, same behaviour) are opening two simultaneous 
connection to the server, I don't know.

I'll try this patch on all my sites now. They're not overloaded so it won't be 
burn-tests but if it can help a bit... :) 

Anyway, thanks for your help.

-- Troll




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

https://bugs.php.net/bug.php?id=52569


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52569&edit=1

Bug #55150 [Asn->Csd]: php -a segfaults

2011-07-11 Thread dmitry

Edit report at https://bugs.php.net/bug.php?id=55150&edit=1

 ID: 55150
 Updated by: dmi...@php.net
 Reported by:hannes dot magnusson at gmail dot com
 Summary:php -a segfaults
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4SVN-2011-07-06 (SVN)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-07-11 03:10:28] dmi...@php.net

Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=313125
Log: Fixed bug #55150 (php -a segfaults)


[2011-07-09 08:02:11] fel...@php.net

It's related to the literals one in interactive mode.


[2011-07-06 14:10:03] hannes dot magnusson at gmail dot com

Description:

Running the following under interactive php shell segfaults :]


Test script:
---
bjori@mini:~/Work/php/5.4$ gdb ./sapi/cli/php 
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
[..]
Reading symbols from 
/home/bjori/Work/src/php/php/php-src/branches/PHP_5_4/sapi/cli/php...done.
(gdb) run -a
Starting program: 
/home/bjori/Work/src/php/php/php-src/branches/PHP_5_4/sapi/cli/php -a
[Thread debugging using libthread_db enabled]
Interactive mode enabled

common.fn_flags & 
(ZEND_ACC_ABSTRACT|ZEND_ACC_DEPRECATED)) != 0)) {
(gdb) bt
#0  0x0072e088 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x77f910e8)
at /home/bjori/Work/php/5.4/Zend/zend_vm_execute.h:580
#1  0x00735921 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x77f910e8)
at /home/bjori/Work/php/5.4/Zend/zend_vm_execute.h:2209
#2  0x0072d1eb in execute (op_array=0x77fc84f0) at 
/home/bjori/Work/php/5.4/Zend/zend_vm_execute.h:410
#3  0x006df3b9 in execute_new_code () at 
/home/bjori/Work/php/5.4/Zend/zend_execute_API.c:1314
#4  0x00699b7e in zendparse () at 
/home/bjori/Work/php/5.4/Zend/zend_language_parser.y:161
#5  0x006a0cbe in compile_file (file_handle=0x7fffddb0, type=8) at 
Zend/zend_language_scanner.l:576
#6  0x006f09da in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/bjori/Work/php/5.4/Zend/zend.c:1213
#7  0x00669f16 in php_execute_script (primary_file=0x7fffddb0) at 
/home/bjori/Work/php/5.4/main/main.c:2382
#8  0x0083098e in do_cli (argc=2, argv=0x7fffe168) at 
/home/bjori/Work/php/5.4/sapi/cli/php_cli.c:990
#9  0x00831856 in main (argc=2, argv=0x7fffe168) at 
/home/bjori/Work/php/5.4/sapi/cli/php_cli.c:1358
(gdb) 







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55150&edit=1

37 matches

Mail list logo