[PHP-BUG] Bug #60841 [NEW]: expand_filepath fails to resolve symlinks that point to \xxx\yyy

[cataphr...@php.net]

From: cataphract
Operating system: Windows 7
PHP version:  5.3.9
Package:  Filesystem function related
Bug Type: Bug
Bug description:expand_filepath fails to resolve symlinks that point to \xxx\yyy

Description:

If a path includes a symlink that points to a path like \xxx\yyy, PHP
understands 
it as a relative path, while it's actually an absolute path (or
quasi-absolute, 
as it doesn't have a drive letter).

Expected result:

foocontents

Actual result:
--
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>cd \

C:\>mkdir t

C:\>mkdir t\test

C:\>mklink /D t\testlink \t\test
symbolic link created for t\testlink <<===>> \t\test

C:\>echo foocontents > \t\testlink\foo

C:\>php -r "echo file_get_contents('t\testlink\foo');"

Warning: file_get_contents(t\testlink\foo): failed to open stream: No such
file
or directory in Command line code on line 1

C:\>php -r "echo file_get_contents('t\test\foo');"
foocontents

C:\>type t\testlink\foo
foocontents

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

[PHP-BUG] Bug #60965 [NEW]: Buffer overflow on htmlspecialchars/entities with $double=false

[cataphr...@php.net]

From: cataphract
Operating system: Any
PHP version:  5.4SVN-2012-02-03 (SVN)
Package:  Reproducible crash
Bug Type: Bug
Bug description:Buffer overflow on htmlspecialchars/entities with $double=false

Description:

Long entities can cause a buffer overflow because the loop only guarantees
40 bytes available in beginning.

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

[PHP-BUG] Bug #61000 [NEW]: Exceeding max nesting level doesn't delete numerical vars

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  trunk-SVN-2012-02-07 (snap)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Exceeding max nesting level doesn't delete numerical vars

Description:

Exceeding the max nesting level doesn't delete numerical vars, while it
deletes the non-numerical ones. php_register_variable_ex inappropriately
uses zend_hash_del.

(Found out by Stefan Esser, who points this can be used, together with
max_input_vars, to determine whether PHP is a 32-bit or 64-bit process)

Test script:
---
With max nesting level=2:

http://nebm.ist.utl.pt/phpinfo?1[a][]=foo&1[a][b][c]=bar



Expected result:

_GET is empty

Actual result:
--
_GET["1"] =
Array
(
[a] => Array
(
[0] => foo
)

)

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

[PHP-BUG] Bug #61253 [NEW]: Wrappers opened with errors concurrency problem

[cataphr...@php.net]

From: cataphract
Operating system: Any (ZTS)
PHP version:  5.4SVN-2012-03-02 (SVN)
Package:  Streams related
Bug Type: Bug
Bug description:Wrappers opened with errors concurrency problem

Description:

When opening the same wrapper in several threads and this generates errors,
a segfault may result.

Test script:
---
http://localhost/notfound');

Expected result:

Each requests shows a 404 error.

Actual result:
--
Segfault given enough concurrency

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

Bug #61253 [PATCH]: Wrappers opened with errors concurrency problem

[cataphr...@php.net]

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

 ID: 61253
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Wrappers opened with errors concurrency problem
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   Any (ZTS)
 PHP Version:5.4SVN-2012-03-02 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61253.diff
Revision:   1330726381
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381


Previous Comments:

[2012-03-02 22:08:08] cataphr...@php.net

Description:

When opening the same wrapper in several threads and this generates errors, a 
segfault may result.

Test script:
---
http://localhost/notfound');

Expected result:

Each requests shows a 404 error.

Actual result:
--
Segfault given enough concurrency






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

Bug #61253 [PATCH]: Wrappers opened with errors concurrency problem

[cataphr...@php.net]

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

 ID: 61253
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Wrappers opened with errors concurrency problem
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   Any (ZTS)
 PHP Version:5.4SVN-2012-03-02 (SVN)
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61253.diff
Revision:   1331129135
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1331129135


Previous Comments:

[2012-03-03 20:42:12] paj...@php.net

Matt, can you test this patch please? and add the test to our suites while 
being 
at it :)


[2012-03-02 22:13:36] cataphr...@php.net

Pierre, please see if this fixes the problem.


[2012-03-02 22:13:02] cataphr...@php.net

The following patch has been added/updated:

Patch Name: bug61253.diff
Revision:   1330726381
URL:
https://bugs.php.net/patch-display.php?bug=61253&patch=bug61253.diff&revision=1330726381


[2012-03-02 22:08:08] cataphr...@php.net

Description:

When opening the same wrapper in several threads and this generates errors, a 
segfault may result.

Test script:
---
http://localhost/notfound');

Expected result:

Each requests shows a 404 error.

Actual result:
--
Segfault given enough concurrency






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

[PHP-BUG] Bug #61374 [NEW]: html_entity_decode tries to decode code points that don't exist in ISO-8859-1

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  5.4SVN-2012-03-13 (SVN)
Package:  *General Issues
Bug Type: Bug
Bug description:html_entity_decode tries to decode code points that don't exist 
in ISO-8859-1

Description:

html_entity_decode tries to decode code points that don't exist in
ISO-8859-1. The result is that the codepoint(s) being written mod 256.

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

[PHP-BUG] Bug #62120 [NEW]: PDO mishandles build outside of tree

[cataphr...@php.net]

From: cataphract
Operating system: Linux
PHP version:  master-Git-2012-05-23 (Git)
Package:  Compile Failure
Bug Type: Bug
Bug description:PDO mishandles build outside of tree

Description:

If you have a different configuration in the tree, when you configure PHP
outside the tree and build PDO, the build will either fail (if you include
pdo-sqlite) or it will fail at runtime due to missing symbols.

Actual result:
--
In file included from /home/gustavo/php-src/main/php_compat.h:27,
 from /home/gustavo/php-src/main/php.h:36,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/tmp/t/main/php_config.h:2179:1: warning: "PHP_BUILD_DATE" redefined
In file included from /tmp/t/TSRM/tsrm_config.h:1,
 from /home/gustavo/php-src/Zend/../TSRM/TSRM.h:20,
 from /home/gustavo/php-src/Zend/zend_alloc.h:27,
 from /home/gustavo/php-src/Zend/zend.h:237,
 from /home/gustavo/php-src/main/php.h:34,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/home/gustavo/php-src/ext/../main/php_config.h:2179:1: warning: this is the
location of the previous definition
In file included from /home/gustavo/php-src/main/php_compat.h:27,
 from /home/gustavo/php-src/main/php.h:36,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/tmp/t/main/php_config.h:2404:1: warning: "ZEND_DEBUG" redefined
In file included from /tmp/t/TSRM/tsrm_config.h:1,
 from /home/gustavo/php-src/Zend/../TSRM/TSRM.h:20,
 from /home/gustavo/php-src/Zend/zend_alloc.h:27,
 from /home/gustavo/php-src/Zend/zend.h:237,
 from /home/gustavo/php-src/main/php.h:34,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/home/gustavo/php-src/ext/../main/php_config.h:2404:1: warning: this is the
location of the previous definition
In file included from /tmp/t/TSRM/tsrm_config.h:1,
 from /home/gustavo/php-src/TSRM/tsrm_config_common.h:13,
 from /home/gustavo/php-src/TSRM/tsrm_virtual_cwd.h:27,
 from /home/gustavo/php-src/main/php.h:401,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/home/gustavo/php-src/ext/../main/php_config.h:2179:1: warning:
"PHP_BUILD_DATE" redefined
In file included from /home/gustavo/php-src/main/php_compat.h:27,
 from /home/gustavo/php-src/main/php.h:36,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/tmp/t/main/php_config.h:2179:1: warning: this is the location of the
previous definition
In file included from /tmp/t/TSRM/tsrm_config.h:1,
 from /home/gustavo/php-src/TSRM/tsrm_config_common.h:13,
 from /home/gustavo/php-src/TSRM/tsrm_virtual_cwd.h:27,
 from /home/gustavo/php-src/main/php.h:401,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/home/gustavo/php-src/ext/../main/php_config.h:2404:1: warning:
"ZEND_DEBUG" redefined
In file included from /home/gustavo/php-src/main/php_compat.h:27,
 from /home/gustavo/php-src/main/php.h:36,
 from /home/gustavo/php-src/ext/pdo_mysql/pdo_mysql.c:26:
/tmp/t/main/php_config.h:2404:1: warning: this is the location of the
previous definition


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

[PHP-BUG] Bug #62690 [NEW]: Sibling property with same name accessible in sibling is detected as accessible

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  master-Git-2012-07-29 (Git)
Package:  Reflection related
Bug Type: Bug
Bug description:Sibling property with same name accessible in sibling is 
detected as accessible

Description:

See script.

Test script:
---
getProperty('var');
echo $prop->getValue(new Qux());

Expected result:

A 'ReflectionException' with message 'Given object is not an instance of
the class this property was declared in'.

This would mirror the behavior with methods:

getMethod('foo');
$meth->invoke(new Qux());

PHP Fatal error:  Uncaught exception 'ReflectionException' with message
'Given object is not an instance of the class this method was declared in'

Actual result:
--
PHP Fatal error:  Cannot access private property Qux::$var

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

[PHP-BUG] Bug #62694 [NEW]: Obtaining the value of inexistent dynamic properties should not be allowed

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  master-Git-2012-07-30 (Git)
Package:  Reflection related
Bug Type: Bug
Bug description:Obtaining the value of inexistent dynamic properties should not 
be allowed

Description:

The reflection extension does not allow obtaining ReflectionProperty
objects for non existent properties, much less fetch their non existent
value. However, this can be bypassed by creating a dynamic
ReflectionProperty in another object.

Test script:
---
foo = "dynamic property";
$ro = new ReflectionObject($a);
$prop = $ro->getProperty('foo');
try {
var_dump($prop->getValue($a));
var_dump($prop->getValue(new A));
} catch (ReflectionException $ex) {
echo "Caught!\n";
try {
var_dump($prop->getValue(new A));
} catch (ReflectionException $ex) {
var_dump($ex->getMessage());
}
}

Expected result:

string(16) "dynamic property"
Caught!
string(49) "Dynamic property does not exist in given instance"

Actual result:
--
string(16) "dynamic property"
NULL

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

[PHP-BUG] Bug #62938 [NEW]: zend_do_bind_catch() used without declaration

[cataphr...@php.net]

From: cataphract
Operating system: Linux/clang
PHP version:  master-Git-2012-08-26 (Git)
Package:  Compile Warning
Bug Type: Bug
Bug description:zend_do_bind_catch() used without declaration

Description:

zend_do_bind_catch() used without declaration. The line that raises the
issue was last modified in c64f4e73.

Actual result:
--
/opt/php-src/Zend/zend_language_parser.y:318:7: warning: implicit
declaration of function 'zend_do_bind_catch' is invalid in C99
[-Wimplicit-function-declaration]
{ zend_do_bind_catch(&(yyvsp[(1) - (6)]), &(yyvsp[(6) - (6)])
TSRMLS_CC); }
  ^
1 warning generated.

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

[PHP-BUG] Bug #51768 [NEW]: Fallback to read_property causes subsequent crash

[cataphr...@php.net]

From: cataphract
Operating system: Windows
PHP version:  5.3.2
Package:  Reproducible crash
Bug Type: Bug
Bug description:Fallback to read_property causes subsequent crash

Description:

When the get_property_ptr_ptr handler is omitted,
zend_fetch_property_address falls back to read_property, but then the
behavior in cases such as

$a = &$obj->prop;

deviates from that of

$a = &$obj['prop'];

which properly emits an error.

The final result is a crash.





Test script:
---
exttest.h:



#ifndef PHP_EXTTEST_H

# define PHP_EXTTEST_H

# ifdef HAVE_CONFIG_H

#  include

# endif

# include

extern zend_module_entry exttest_module_entry;

#define phpext_exttest_ptr &exttest_module_entry

#endif



exttest.c:

#include "exttest.h"



static zend_object_handlers object_handlers;



static zend_object_value ce_create_object(zend_class_entry *class_type
TSRMLS_DC)

{

zend_object_value zov;

zend_object   *zobj;



zobj = emalloc(sizeof *zobj);

zend_object_std_init(zobj, class_type TSRMLS_CC);



zend_hash_copy(zobj->properties, &(class_type->default_properties),

(copy_ctor_func_t) zval_add_ref, NULL, sizeof(zval*));

zov.handle = zend_objects_store_put(zobj,

(zend_objects_store_dtor_t) zend_objects_destroy_object,

(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,

NULL TSRMLS_CC);

zov.handlers = &object_handlers;

return zov;

}



ZEND_MODULE_STARTUP_D(exttest)

{

zend_class_entry ce;

zend_class_entry *ce_ptr;

zval *property;



ALLOC_PERMANENT_ZVAL(property);

INIT_ZVAL(*property);

Z_TYPE_P(property) = IS_LONG;

Z_LVAL_P(property) = 20l;



memcpy(&object_handlers, zend_get_std_object_handlers(),

sizeof object_handlers);

object_handlers.get_property_ptr_ptr = NULL;



INIT_CLASS_ENTRY(ce, "TestClass", NULL);

ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);

ce_ptr->create_object = ce_create_object;

zend_declare_property_ex(ce_ptr, "prop", 4, property, ZEND_ACC_PUBLIC,

NULL, 0 TSRMLS_CC);

}



zend_module_entry exttest_module_entry = {

STANDARD_MODULE_HEADER,

"exttest",

NULL, /* Functions */

ZEND_MODULE_STARTUP_N(exttest) , /* MINIT */

NULL, /* MSHUTDOWN */

NULL, /* RINIT */

NULL, /* RSHUTDOWN */

NULL, /* MINFO */

NO_VERSION_YET,

STANDARD_MODULE_PROPERTIES

};



ZEND_GET_MODULE(exttest)



config.m4:

PHP_ARG_ENABLE(exttest,

  [Whether to enable the "exttest" extension],

  [  enable-exttest Enable "exttest" extension support])



if test $PHP_EXTTEST != "no"; then

  PHP_SUBST(EXTTEST_SHARED_LIBADD)

  PHP_NEW_EXTENSION(exttest, exttest.c, $ext_shared)

fi





test.php:

prop;

debug_zval_dump($obj);

debug_zval_dump(&$a);

$a = 40;

debug_zval_dump($obj);

debug_zval_dump(&$a);

unset($a);

debug_zval_dump($obj);



Expected result:

Expected an error saying the operation is not permitted (like when
attempting $a = &obj['index'] where there's no get_property_ptr_ptr
equivalent).

Actual result:
--
When thre's get_property_ptr_ptr:



object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(20) refcount(2)

}

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  &long(20) refcount(2)

}

&long(20) refcount(3)

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  &long(40) refcount(2)

}

&long(40) refcount(3)

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(40) refcount(1)

}



When there's no get_property_ptr_ptr, zend_fetch_property_address falls
back to read_propert. Something happens afterwards that provokes the
crash.



object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(20) refcount(2)

}

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(20) refcount(1)

}

&long(20) refcount(3)

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(20) refcount(1)

}

&long(40) refcount(3)

object(TestClass)#1 (1) refcount(2){

  ["prop"]=>

  long(20) refcount(1)

}

Segmentation fault



#0  0x081d60ae in zend_mm_check_ptr (heap=0x83881b8, ptr=0x840ca90,
silent=1,

__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,

__zend_orig_filename=0x83621b8
"/home/glopes/php/php-5.3.2/Zend/zend_execute_API.c",

__zend_orig_lineno=440) at
/home/glopes/php/php-5.3.2/Zend/zend_alloc.c:1347

#1  0x081d768d in _zend_mm_free_int (heap=0x83881b8, p=0x840ca90,

__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,

__zend_orig_filename=0x83621b8
"/home/glopes/php/php-5.3.2/Zend/zend_execute_API.c",

__zend_orig_lineno=440) at
/home/glopes/php/php-5.3.2/Zend/zend_alloc.c:1983

#2  0x081d86bb in _efree (ptr=0x840ca90,

__zend_filename=0x83633a0
"/home/glopes/php/php-5.3.2/Zend/zend_variables.c", __zend_lineno=178,

__zend_orig_filename=0x83621b8
"/home/glopes/php/ph

Bug #51763 [Com]: SplFileInfo::getType()

[cataphr...@php.net]

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

 ID:   51763
 Comment by:   cataphr...@php.net
 Reported by:  v-sumada at microsoft dot com
 Summary:  SplFileInfo::getType()
 Status:   Open
 Type: Bug
 Package:  SPL related
 Operating System: All windows OS
 PHP Version:  5.3.2

 New Comment:

The comment should read "information is NOT conveyed in the stat
structure".


Previous Comments:

[2010-05-08 05:05:38] cataphr...@php.net

This is unrelated to Spl. is_link/etc. are all also windows symbolic
link agnostic. The problem here is that this information is conveyed in
the stat structure. Strictly speaking, the return of getType is not
completely incorrect -- the file type _S_IFREG and symbolic links are in
fact files or (empty) directories with reparse point data. Maybe the
best thing to do would be to change the stat function returned on
windows so that the file type is replaced with _S_IFLNK when the
directory is a junction/symlink or the file is a symlink.


[2010-05-07 03:36:11] v-sumada at microsoft dot com

Description:

The SplFileInfo::getType() For Symbolic link returns "dir" which in turn
should return "link" .This happens to be in 5.3.2 and occurs on all
windows OS.



It Correctly  returns the type of  file referenced which is for Dir  and
File . 





getType());

?>



Expected result :string(4)"Link"

Actual result : string(3) "dir" 

Test script:
---
getType());

?>

Expected result:

string(4)"Link"





Actual result:
--
string(3) "dir" 






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

[PHP-BUG] Bug #52063 [NEW]: DateTime constructor's second argument doesn't have a null default value

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  5.3.2
Package:  Date/time related
Bug Type: Bug
Bug description:DateTime constructor's second argument doesn't have a null 
default value

Description:

DateTime's constructor is documented like this:



public DateTime::__construct ([ string $time = "now" [, DateTimeZone
$timezone = NULL ]] )



However, not passing the constructor the second argument is not the same as
passing NULL. Fixing this is just a matter of adding a "!", like this



if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {



into



if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO!",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {

Test script:
---
format(DateTime::COOKIE);

Expected result:

Thursday, 01-Jan-09 00:00:00 WET

Actual result:
--
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() expects parameter 2 to be DateTimeZone, null
given' in /tmp/cpCZPA42:4 Stack trace: #0 /tmp/cpCZPA42(4):
DateTime->__construct('2009-01-01', NULL) #1 {main} thrown in /tmp/cpCZPA42
on line 4

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

[PHP-BUG] Bug #52539 [NEW]: Calling function from rebound Closure causes crash

[cataphr...@php.net]

From: cataphract
Operating system: Windows
PHP version:  trunk-SVN-2010-08-05 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Calling function from rebound Closure causes crash

Description:

Calling a function in a rebound closure causes a crash.



This seems to be caused by dmitry's optimizations because this fixes the
issue:

#define CACHED_PTR(num) 0.

Test script:
---
class foo {

static function getClosure() {

return static function () {

//causes a crash (fbc not properly defined) in call 
after rebinding

echo get_called_class(), "\n";

};

}

}

 

class subFoo { }

 

$c = foo::getClosure();

$c(); //foo

$c = $c->bindTo(new subFoo());

$c(); //crash

Expected result:

No crash.

Actual result:
--
>   php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8)  Line 302 + 0x3
bytes   C

php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8)  Line 1721  C

php5ts_debug.dll!execute(_zend_op_array * op_array=0x025f23c8, void * * 
*
tsrm_ls=0x02784bf8)  Line 136 + 0x11 bytes  C

php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x02784bf8, _zval_struct * * retval=0x, int file_count=3,
...)  Line 1193 + 0x21 bytesC

php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x00aaf7b0, void * * * tsrm_ls=0x02784bf8)  Line 2330 + 0x1b
bytes   C

php.exe!main(int argc=2, char * * argv=0x02784af8)  Line 1252 + 0x13
bytes   C



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

Bug #52539 [PATCH]: Calling function from rebound Closure causes crash

[cataphr...@php.net]

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

 ID: 52539
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Calling function from rebound Closure causes crash
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows
 PHP Version:trunk-SVN-2010-08-05 (SVN)
 Assigned To:dmitry
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: patch_closures_rebind
Revision:   1281277806
URL:   
http://bugs.php.net/patch-display.php?bug=52539&patch=patch_closures_rebind&revision=1281277806


Previous Comments:

[2010-08-05 09:34:56] cataphr...@php.net

Description:

Calling a function in a rebound closure causes a crash.



This seems to be caused by dmitry's optimizations because this fixes the
issue:

#define CACHED_PTR(num) 0.

Test script:
---
class foo {

static function getClosure() {

return static function () {

//causes a crash (fbc not properly defined) in call 
after rebinding

echo get_called_class(), "\n";

};

}

}

 

class subFoo { }

 

$c = foo::getClosure();

$c(); //foo

$c = $c->bindTo(new subFoo());

$c(); //crash

Expected result:

No crash.

Actual result:
--
>   php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8)  Line 302 + 0x3
bytes   C

php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x025d2298, void * * * tsrm_ls=0x02784bf8)  Line 1721  C

php5ts_debug.dll!execute(_zend_op_array * op_array=0x025f23c8, void *
* * tsrm_ls=0x02784bf8)  Line 136 + 0x11 bytes  C

php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x02784bf8, _zval_struct * * retval=0x, int
file_count=3, ...)  Line 1193 + 0x21 bytes  C

php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x00aaf7b0, void * * * tsrm_ls=0x02784bf8)  Line 2330 +
0x1b bytes  C

php.exe!main(int argc=2, char * * argv=0x02784af8)  Line 1252 + 0x13
bytes   C








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

[PHP-BUG] Bug #52772 [NEW]: var_dump() doesn't check for the existence of get_class_name before calling it

[cataphr...@php.net]

From: cataphract
Operating system: Windows
PHP version:  trunk-SVN-2010-09-04 (snap)
Package:  Variables related
Bug Type: Bug
Bug description:var_dump() doesn't check for the existence of get_class_name 
before calling it

Description:

php_var_dump has a NULL pointer dereference in var.c:136



Z_OBJ_HANDLER(**struc, get_class_name)(*struc, &class_name,
&class_name_len, 0 TSRMLS_CC);



It doesn't check the existence of the handler get_class_name before
calling. In particular, it will crash when given a proxy object.



The engine always checks for the existence of this handler before calling.
See e.g. the definitions of ZEND_FUNCTION(get_parent_class) and
zend_print_flat_zval_r:



http://lxr.php.net/search?q=%22ZEND_FUNCTION%28get_parent_class%29%22&project=PHP_TRUNK&defs=&refs=&path=&hist=

http://lxr.php.net/search?q=zend_print_flat_zval_r&project=PHP_TRUNK&defs=&refs=&path=&hist=

Test script:
---
/* Extension */





typedef struct _proxy_test {

zend_object std;

long value;

} proxy_test;

static zend_class_entry *pt_ce_ptr;

static zend_object_handlers p_obj_handlers;

static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)

{

zend_object_value zov;

proxy_test   *pobj;



pobj = emalloc(sizeof *pobj);

zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);

pobj->value = 7;



object_properties_init(&pobj->std, class_type);

zov.handle = zend_objects_store_put(pobj,

(zend_objects_store_dtor_t) zend_objects_destroy_object,

(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,

NULL TSRMLS_CC);

zov.handlers = &p_obj_handlers;

return zov;

}

zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {

zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);

Z_DELREF_P(ret);

return ret;

} else {

zval *ret;

MAKE_STD_ZVAL(ret);

ZVAL_LONG(ret, iobj->value);

Z_DELREF_P(ret);

return ret;

}

}



void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (Z_TYPE_P(value) == IS_LONG) {

iobj->value = Z_LVAL_P(value);

}

}

zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)

{

return NULL;

}



/*static zend_function_entry proxy_test_methods[] = {

{NULL, NULL, NULL, 0, 0}

};*/



ZEND_MODULE_STARTUP_D(testext)

{

zend_class_entry ce;



INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);

pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);

pt_ce_ptr->create_object = p_ce_create_object;

memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);

/* could be NULL, but an empty impl is better (see bug #51768) */

p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;

p_obj_handlers.read_property = p_read_property;

p_obj_handlers.write_property = p_write_property;

}



/* Script */



whatever;

var_dump($h); NULL-pointer dereference on handler get_class_name

Expected result:

No crash. Possibly, var_dump could show "proxy object" and show the zval
returned by the get handler or it could just fail.

Actual result:
--
()  

>   php5ts_debug.dll!php_var_dump(_zval_struct * * struc=0x010a22a8, int
level=1, void * * * tsrm_ls=0x00fc4bf8)  Line 136 + 0x23 bytes  C

php5ts_debug.dll!zif_var_dump(int ht=1, _zval_struct *
return_value=0x010bf3f0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x, int return_value_used=0, void * * *
tsrm_ls=0x00fc4bf8)  Line 181 + 0x15 bytes  C

php5ts_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x010a20d8, void * * * tsrm_ls=0x00fc4bf8)  Line 638 + 0x5f
bytes   C

php5ts_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data=0x010a20d8, void * * * tsrm_ls=0x00fc4bf8)  Line 2018  C

php5ts_debug.dll!execute(_zend_op_array * op_array=0x010c0dc8, void * * 
*
tsrm_ls=0x00fc4bf8)  Line 410 + 0x11 bytes  C

php5ts_debug.dll!zend_execute_scripts(int type=8, void * * *
tsrm_ls=0x00fc4bf8, _zval_struct * * retval=0x, int file_count=3,
...)  Line 1193 + 0x21 bytesC

php5ts_debug.dll!php_execute_script(_zend_file_handle *
primary_file=0x0095fb48, void * * * tsrm_ls=0x00fc4bf8)  Line 2330 + 0x1b
bytes   C

[PHP-BUG] Bug #52773 [NEW]: Proxy objects have an inadequate destroy_object store callback

[cataphr...@php.net]

From: cataphract
Operating system: Windows
PHP version:  trunk-SVN-2010-09-04 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Proxy objects have an inadequate destroy_object store callback

Description:

zend_object_create_proxy calls zend_objects_store_put with the second
argument NULL:



See the definition of zend_object_create-proxy:



http://lxr.php.net/search?q=zend_object_create_proxy&project=PHP_TRUNK&defs=&refs=&path=&hist=



This results in the _store_object.dtor store callback being set to
zend_objects_destroy_object. See the definition of zend_objects_store_put:



http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_objects_API.c#zend_objects_store_put



This callback is defined here:



http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_objects.c#zend_objects_destroy_object



It is inappropriate because it starts with:



ZEND_API void zend_objects_destroy_object(zend_object *object,
zend_object_handle handle TSRMLS_DC)

{

zend_function *destructor = object ? object->ce->destructor : NULL;



The first parameter won't actually be a zend_object; it'll be a
zend_proxy_object, whose definition is not compatible with that of
zend_object:



typedef struct _zend_object {

zend_class_entry *ce;

HashTable *properties;

zval **properties_table;

HashTable *guards; /* protects from __get/__set ... recursion */

} zend_object;



typedef struct _zend_proxy_object {

zval *object;

zval *property;

} zend_proxy_object;

Test script:
---
/* Extension */





typedef struct _proxy_test {

zend_object std;

long value;

} proxy_test;

static zend_class_entry *pt_ce_ptr;

static zend_object_handlers p_obj_handlers;

static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)

{

zend_object_value zov;

proxy_test   *pobj;



pobj = emalloc(sizeof *pobj);

zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);

pobj->value = 7;



object_properties_init(&pobj->std, class_type);

zov.handle = zend_objects_store_put(pobj,

(zend_objects_store_dtor_t) zend_objects_destroy_object,

(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,

NULL TSRMLS_CC);

zov.handlers = &p_obj_handlers;

return zov;

}

zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {

zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);

Z_DELREF_P(ret);

return ret;

} else {

zval *ret;

MAKE_STD_ZVAL(ret);

ZVAL_LONG(ret, iobj->value);

Z_DELREF_P(ret);

return ret;

}

}



void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (Z_TYPE_P(value) == IS_LONG) {

iobj->value = Z_LVAL_P(value);

}

}

zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)

{

return NULL;

}



/*static zend_function_entry proxy_test_methods[] = {

{NULL, NULL, NULL, 0, 0}

};*/



ZEND_MODULE_STARTUP_D(testext)

{

zend_class_entry ce;



INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);

pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);

pt_ce_ptr->create_object = p_ce_create_object;

memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);

/* could be NULL, but an empty impl is better (see bug #51768) */

p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;

p_obj_handlers.read_property = p_read_property;

p_obj_handlers.write_property = p_write_property;

}



/* Script */



whatever;

unset($h);

Expected result:

zend_objects_destroy_object should not be the proxy object's destructor.

A no-op destructor should be passed to the store_put function.

Actual result:
--
I didn't get a crash by change (the memory in object->ce->destructor turned
out to be zeroed, which makes zend_objects_destroy_object skip the
implementation), but we can see this doesn't make sense:



Breakpoint with this stack:



>   php5ts_debug.dll!zend_objects_destroy_object(_zend_object *
object=0x011bf680, unsigned int handle=2, void * * * tsrm_ls=0x001d15f8) 
Line 62 C

php5ts_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int
handle=2, const _zend_object_handlers * handlers=0x5d6fb848, void * * *
tsrm_ls=0x001d15f8)  Line 206 + 0x18 bytes  C

php5ts_debug.dll!zend_obje

[PHP-BUG] Bug #52774 [NEW]: Proxy object's store free callback calls zval_ptor_dtor on already freed data

[cataphr...@php.net]

From: cataphract
Operating system: 
PHP version:  trunk-SVN-2010-09-04 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Proxy object's store free callback calls zval_ptor_dtor on 
already freed data

Description:

Proxy objects have this structure:



typedef struct _zend_proxy_object {

zval *object;

zval *property;

} zend_proxy_object;



zend_object_create_proxy does this:



ZEND_API zval *zend_object_create_proxy(zval *object, zval *member
TSRMLS_DC)

{

zend_proxy_object *pobj = emalloc(sizeof(zend_proxy_object));

/* ... */

pobj->property = member;

zval_add_ref(&pobj->property);

/* ... */

}



The property field is used to store a zval that, in the get and set
handlers can the passed to zend_proxy_object.object's read_property and
write_property callbacks, so that the reads and writes in the proxy object
can be proxied.



The store free callback for proxy objects calls zval_ptr_tor on
&pobj->property:



ZEND_API void zend_objects_proxy_free_storage(zend_proxy_object *object
TSRMLS_DC)

{

zval_ptr_dtor(&object->object);

zval_ptr_dtor(&object->property);

efree(object);

}



However, on script cleanup, the destruction order is wrong. The zval stored
in object->property is destroyed *before* the proxy object is.

Test script:
---
/* Extension */





typedef struct _proxy_test {

zend_object std;

long value;

} proxy_test;

static zend_class_entry *pt_ce_ptr;

static zend_object_handlers p_obj_handlers;

static zend_object_value p_ce_create_object(zend_class_entry *class_type
TSRMLS_DC)

{

zend_object_value zov;

proxy_test   *pobj;



pobj = emalloc(sizeof *pobj);

zend_object_std_init((zend_object *) pobj, class_type TSRMLS_CC);

pobj->value = 7;



object_properties_init(&pobj->std, class_type);

zov.handle = zend_objects_store_put(pobj,

(zend_objects_store_dtor_t) zend_objects_destroy_object,

(zend_objects_free_object_storage_t)
zend_objects_free_object_storage,

NULL TSRMLS_CC);

zov.handlers = &p_obj_handlers;

return zov;

}

zval *p_read_property(zval *object, zval *member, int type, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (type == BP_VAR_W || type == BP_VAR_RW || type == BP_VAR_UNSET) {

zval *ret = zend_object_create_proxy(object, member TSRMLS_CC);

Z_DELREF_P(ret);

return ret;

} else {

zval *ret;

MAKE_STD_ZVAL(ret);

ZVAL_LONG(ret, iobj->value);

Z_DELREF_P(ret);

return ret;

}

}



void p_write_property(zval *object, zval *member, zval *value, const struct
_zend_literal *key TSRMLS_DC)

{

proxy_test *iobj = zend_object_store_get_object(object TSRMLS_CC);

if (Z_TYPE_P(value) == IS_LONG) {

iobj->value = Z_LVAL_P(value);

}

}

zval **p_get_property_ptr_ptr(zval *object, zval *member, const struct
_zend_literal *key TSRMLS_DC)

{

return NULL;

}



ZEND_MODULE_STARTUP_D(testext)

{

zend_class_entry ce;



INIT_CLASS_ENTRY(ce, "ProxyTestClass", NULL);

pt_ce_ptr = zend_register_internal_class(&ce TSRMLS_CC);

pt_ce_ptr->create_object = p_ce_create_object;

memcpy(&p_obj_handlers, zend_get_std_object_handlers(), sizeof
p_obj_handlers);

/* could be NULL, but an empty impl is better (see bug #51768) */

p_obj_handlers.get_property_ptr_ptr = p_get_property_ptr_ptr;

p_obj_handlers.read_property = p_read_property;

p_obj_handlers.write_property = p_write_property;

}



/* Script */



whatever;

Expected result:

The proxy object would be destroyed before the property zval encapsulated
in it.

Actual result:
--
The property zval encapsulated in the proxy object is destroyed
prematurely.



Breakpoint on zend_object_create_proxy. Set data breakpoint on
&member->refcount__gc



Continue. Data breakpoint is hit (zval_add_ref(&pobj->property);). The
refcount is now 3.



Continue. Data breakpoint is hit. Call stack:



>   msvcr100d.dll!memset(unsigned char * dst=0x005a, unsigned char
value='`', unsigned long count=11071032)  Line 127  Asm

php5ts_debug.dll!_zend_mm_free_int(_zend_mm_heap * heap=0x02426d50, void
* p=0x028101a0, const char * __zend_filename=0x5d637b70, const unsigned int
__zend_lineno=397, const char * __zend_orig_filename=0x, const
unsigned int __zend_orig_lineno=0)  Line 2019 + 0x15 bytes  C

php5ts_debug.dll!_efree(void * ptr=0x028101a0, const char *
__zend_filename=0x5d637b70, const unsigned int __zend_lineno=397, const
char * __zend_orig_filename=0x, const unsigned int
__zend_orig_lineno=0) 

[PHP-BUG] Bug #52785 [NEW]: CGI: error_log may result in output before the headers

[cataphr...@php.net]

From: cataphract
Operating system: Debian Lenny
PHP version:  5.3.3
Package:  CGI related
Bug Type: Bug
Bug description:CGI: error_log may result in output before the headers

Description:

A call to error_log may result in data being output before the headers,
thereby corrupting the response.



The same doesn't happen with other PHP output functions.



The ini directive error_log is set to "no value". The docs say "If this
directive is not set, errors are sent to the SAPI error logger".

Test script:
---


Fatal error:  Call to undefined function inexistent_function() in
/home/glopes/test.php on line 4



Actual result:
--
$ /opt/php5/bin/php-cgi test.php

oops

X-Powered-By: PHP/5.3.3

Content-type: text/html



content

Fatal error:  Call to undefined function inexistent_function() in
/home/glopes/test.php on line 4



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

Bug #50953 [PATCH]: fsockopen will not work on 'localhost'

[cataphr...@php.net]

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

 ID: 50953
 Patch added by: cataphr...@php.net
 Reported by:tony at marston-home dot demon dot co dot uk
 Summary:fsockopen will not work on 'localhost'
 Status: Bogus
 Type:   Bug
 Package:Sockets related
 Operating System:   Windows XP
 PHP Version:5.2.12
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: connect_fix_win32
Revision:   1283848007
URL:   
http://bugs.php.net/patch-display.php?bug=50953&patch=connect_fix_win32&revision=1283848007


Previous Comments:

[2010-02-12 14:22:47] tony at marston-home dot demon dot co dot uk

If IPv6 support is enabled in the operating system it does NOT mean that
only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.



All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.



The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.



The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.



fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.



So why does fsockopen() in php 5.2.12 have a problem?


[2010-02-10 11:27:25] tony at marston-home dot demon dot co dot uk

This has got nothing to do with IPV6 addresses as my hosts file does not
contain anf IPV6 addresses. All it has is as follows:



127.0.0.1   localhost



Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.



I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2



Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.



If gethostbyname() can work with 'localhost' then why can't fsockopen()?


[2010-02-10 11:06:08] paj...@php.net

It works just fine here using localhost and ipv4.



You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).



I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.


[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk

THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!



If print_r(gethostbynamel('localhost'));  produces the following:



Array

(

[0] => 127.0.0.1

)



then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.



I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2


[2010-02-10 10:18:16] paj...@php.net

Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=50953


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

Bug #52789 [Com]: microtime() loses time in long-running scripts (please reopen)

[cataphr...@php.net]

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

 ID: 52789
 Comment by: cataphr...@php.net
 Reported by:jdolecek at NetBSD dot org
 Summary:microtime() loses time in long-running scripts
 (please reopen)
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows XP
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

I ran the script for two hours and a half and couldn't reproduce it. Is
this XP only?


Previous Comments:

[2010-09-07 09:40:11] jdolecek at NetBSD dot org

Description:

This is just a reminder for Bug #42659 since I cannot reopen that one.
The problem with time difference between time() and microtime() on
Windows XP is still there.



Please reopen Bug #42659







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

Bug #52798 [PATCH]: dateTime => function diff => days KO

[cataphr...@php.net]

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

 ID: 52798
 Patch added by: cataphr...@php.net
 Reported by:ebinachon at pierre-vacances dot fr
 Summary:dateTime => function diff => days KO
 Status: Verified
 Type:   Bug
 Package:Date/time related
 Operating System:   windows xp
 PHP Version:5.3.3
 Assigned To:derick
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: date_diff
Revision:   1283961826
URL:   
http://bugs.php.net/patch-display.php?bug=52798&patch=date_diff&revision=1283961826


Previous Comments:

[2010-09-08 17:36:02] cataphr...@php.net

I can reproduce only on Windows. The exactly value varies (seems to be
garbage memory).


[2010-09-08 17:19:52] ebinachon at pierre-vacances dot fr

Description:

I have a probleme with the function diff of dateTime.

When i do a test, the "days" result is always : 6015.

All the other informations ( Y, m, d, ... ) are correct.



Have-you an idea ?



Test script:
---
Exemple :

$date1 = new DateTime('2010-01-01');

$date2 = new DateTime('2010-03-13');

$interval = $date2->diff($date1);

Zend_Debug::dump($interval);

//OR 

Zend_Debug::dump($interval->format('%a'));



--



Result :

object(DateInterval)#174 (8) {

  ["y"] => int(0)

  ["m"] => int(2)

  ["d"] => int(12)

  ["h"] => int(0)

  ["i"] => int(0)

  ["s"] => int(0)

  ["invert"] => int(0)

  ["days"] => int(6015)

}

Expected result:

days => 71

Actual result:
--
days => 6015






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

[PHP-BUG] Bug #52802 [NEW]: Out-of-date comment for file_get_contents/php_stream_copy_to_mem

[cataphr...@php.net]

From: cataphract
Operating system: 
PHP version:  trunk-SVN-2010-09-09 (SVN)
Package:  Streams related
Bug Type: Bug
Bug description:Out-of-date comment for file_get_contents/php_stream_copy_to_mem

Description:

ext/standard/file.c#560



560 /* uses mmap if possible */

561 if ((len = php_stream_copy_to_mem(stream, &contents, maxlen, 
0)) >
0) {



main/php_streams.h



431 /* read all data from stream and put into a buffer. Caller must
free buffer when done.

432  * The copy will use mmap if available. */

433 PHPAPI size_t _php_stream_copy_to_mem(php_stream *src, char **buf,
size_t maxlen,

434 int persistent STREAMS_DC TSRMLS_DC);

435 #define php_stream_copy_to_mem(src, buf, maxlen, persistent)
_php_stream_copy_to_mem((src), (buf), (maxlen), (persistent) STREAMS_CC
TSRMLS_CC)



main/php_streams.h



419 /* copy up to maxlen bytes from src to dest.  If maxlen is
PHP_STREAM_COPY_ALL, copy until eof(src).

420  * Uses mmap if the src is a plain file and at offset 0 */

421 #define PHP_STREAM_COPY_ALL ((size_t)-1)



In this last case, PHP_STREAM_COPY_ALL is also passed to
php_stream_copy_to_stream_ex, which still uses mmap+mmap_unmap, so it's
half correct (except for the part is works with any maxlen, not just
PHP_STREAM_COPY_ALL).


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

Bug #52802 [Com]: Out-of-date comment for file_get_contents/php_stream_copy_to_mem

[cataphr...@php.net]

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

 ID: 52802
 Comment by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Out-of-date comment for
 file_get_contents/php_stream_copy_to_mem
 Status: Open
 Type:   Bug
 Package:Streams related
 PHP Version:trunk-SVN-2010-09-09 (SVN)
 Block user comment: N

 New Comment:

Forgot the tell. The behavior of php_stream_copy_to_mem was modified in
March 2008:



http://svn.php.net/viewvc?view=revision&revision=255970


Previous Comments:

[2010-09-09 13:36:58] cataphr...@php.net

Description:

ext/standard/file.c#560



560 /* uses mmap if possible */

561 if ((len = php_stream_copy_to_mem(stream, &contents, maxlen,
0)) > 0) {



main/php_streams.h



431 /* read all data from stream and put into a buffer. Caller must
free buffer when done.

432  * The copy will use mmap if available. */

433 PHPAPI size_t _php_stream_copy_to_mem(php_stream *src, char
**buf, size_t maxlen,

434 int persistent STREAMS_DC TSRMLS_DC);

435 #define php_stream_copy_to_mem(src, buf, maxlen, persistent)
_php_stream_copy_to_mem((src), (buf), (maxlen), (persistent) STREAMS_CC
TSRMLS_CC)



main/php_streams.h



419 /* copy up to maxlen bytes from src to dest.  If maxlen is
PHP_STREAM_COPY_ALL, copy until eof(src).

420  * Uses mmap if the src is a plain file and at offset 0 */

421 #define PHP_STREAM_COPY_ALL ((size_t)-1)



In this last case, PHP_STREAM_COPY_ALL is also passed to
php_stream_copy_to_stream_ex, which still uses mmap+mmap_unmap, so it's
half correct (except for the part is works with any maxlen, not just
PHP_STREAM_COPY_ALL).







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

[PHP-BUG] Bug #52827 [NEW]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)

[cataphr...@php.net]

From: cataphract
Operating system: Ubuntu 10.4 x64; Windows 7 x64
PHP version:  5.3.3
Package:  cURL related
Bug Type: Bug
Bug description:cURL leaks handle and causes assertion error (CURLOPT_STDERR)

Description:

curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval* and
increments both the refcount of the zval* and of the resource.



Only the refcount of the zval should be incremented.



Additionally, due to a flaw in the streams API, this leak results in an
assertion error. The reason is that on shutdown the unexposed/leaked
resources are destroyed in reverse order, so the encapsulated STDIO stream
is destroyed first and when the TEMP stream is destroyed, it then tries to
close the encapsulated STDIO steam again. I will submit this as a separate
bug report.

Test script:
---
http://www.example.com');

curl_setopt($handle, CURLOPT_STDERR, $s);

Expected result:

No output.

Actual result:
--
(with stream debug)



stream_alloc: TEMP:0x12a61b0 persistent=(null)

stream_alloc: MEMORY:0x12a6488 persistent=(null)

stream_alloc: STDIO:0x12a6f90 persistent=(null)

stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003

stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1
remove_rs  rc=1

stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0
release_cast=1 re  move_rsrc=1

/tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO'
0x12a6f90 (p  ath:/tmp/phpghmjqQ) was not closed

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0
opts=000b

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0
release  _cast=1 remove_rsrc=1

php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush:
Assertio  n `data != ((void *)0)' failed.

Aborted







#0  0x7f74b5a22ed5 in raise () from /lib/libc.so.6

#1  0x7f74b5a243f3 in abort () from /lib/libc.so.6

#2  0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6

#3  0x0076129e in php_stdiop_flush (stream=0x1049dc8)

at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434

#4  0x007596dd in _php_stream_flush (stream=0x1049dc8, closing=0)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#5  0x0075df57 in php_stream_temp_flush (stream=0x1049050)

at /tmp/php-5.3.3/main/streams/memory.c:440

#6  0x007596dd in _php_stream_flush (stream=0x1049050, closing=1)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#7  0x00757b4d in _php_stream_free (stream=0x1049050,
close_options=11)

at /tmp/php-5.3.3/main/streams/streams.c:331

#8  0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48)

at /tmp/php-5.3.3/main/streams/streams.c:1426

#9  0x007c4f9e in list_entry_destructor (ptr=0x104ab48)

at /tmp/php-5.3.3/Zend/zend_list.c:184

#10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650,
p=0x1049198)

at /tmp/php-5.3.3/Zend/zend_hash.c:611

#11 0x007c25ff in zend_hash_graceful_reverse_destroy (ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_hash.c:646

#12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_list.c:240

#13 0x007b1549 in zend_deactivate () at
/tmp/php-5.3.3/Zend/zend.c:896

#14 0x0073e71b in php_request_shutdown (dummy=0x0)

at /tmp/php-5.3.3/main/main.c:1633

#15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8)

at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373



-- 
Edit bug report at http://bugs.php.net/bug.php?id=52827&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52827&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52827&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52827&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52827&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52827&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52827&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52827&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52827&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52827&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52827&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52827&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52827&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52827&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52827&r=globals
PHP 4 support discontinued:  

Bug #52827 [PATCH]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)

[cataphr...@php.net]

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

 ID: 52827
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:cURL leaks handle and causes assertion error
 (CURLOPT_STDERR)
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Ubuntu 10.4 x64; Windows 7 x64
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: curlopt_stderr
Revision:   1284389761
URL:   
http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761


Previous Comments:

[2010-09-13 16:55:39] cataphr...@php.net

Description:

curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval*
and increments both the refcount of the zval* and of the resource.



Only the refcount of the zval should be incremented.



Additionally, due to a flaw in the streams API, this leak results in an
assertion error. The reason is that on shutdown the unexposed/leaked
resources are destroyed in reverse order, so the encapsulated STDIO
stream is destroyed first and when the TEMP stream is destroyed, it then
tries to close the encapsulated STDIO steam again. I will submit this as
a separate bug report.

Test script:
---
http://www.example.com');

curl_setopt($handle, CURLOPT_STDERR, $s);

Expected result:

No output.

Actual result:
--
(with stream debug)



stream_alloc: TEMP:0x12a61b0 persistent=(null)

stream_alloc: MEMORY:0x12a6488 persistent=(null)

stream_alloc: STDIO:0x12a6f90 persistent=(null)

stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003

stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1
remove_rs  rc=1

stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0
release_cast=1 re  move_rsrc=1

/tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO'
0x12a6f90 (p  ath:/tmp/phpghmjqQ) was not closed

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0
opts=000b

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0
release  _cast=1 remove_rsrc=1

php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush:
Assertio  n `data != ((void *)0)' failed.

Aborted







#0  0x7f74b5a22ed5 in raise () from /lib/libc.so.6

#1  0x7f74b5a243f3 in abort () from /lib/libc.so.6

#2  0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6

#3  0x0076129e in php_stdiop_flush (stream=0x1049dc8)

at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434

#4  0x007596dd in _php_stream_flush (stream=0x1049dc8,
closing=0)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#5  0x0075df57 in php_stream_temp_flush (stream=0x1049050)

at /tmp/php-5.3.3/main/streams/memory.c:440

#6  0x007596dd in _php_stream_flush (stream=0x1049050,
closing=1)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#7  0x00757b4d in _php_stream_free (stream=0x1049050,
close_options=11)

at /tmp/php-5.3.3/main/streams/streams.c:331

#8  0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48)

at /tmp/php-5.3.3/main/streams/streams.c:1426

#9  0x007c4f9e in list_entry_destructor (ptr=0x104ab48)

at /tmp/php-5.3.3/Zend/zend_list.c:184

#10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650,
p=0x1049198)

at /tmp/php-5.3.3/Zend/zend_hash.c:611

#11 0x007c25ff in zend_hash_graceful_reverse_destroy
(ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_hash.c:646

#12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_list.c:240

#13 0x007b1549 in zend_deactivate () at
/tmp/php-5.3.3/Zend/zend.c:896

#14 0x0073e71b in php_request_shutdown (dummy=0x0)

at /tmp/php-5.3.3/main/main.c:1633

#15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8)

at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373








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

[PHP-BUG] Bug #52828 [NEW]: curl_setopt does not accept persistent streams

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  5.3.3
Package:  cURL related
Bug Type: Bug
Bug description:curl_setopt does not accept persistent streams

Description:

The options CURLOPT_FILE, CURLOPT_INFILE, CURLOPT_WRITEHEADER and
CURLOPT_STDERR do not accept persistent handles.



Since there appears to be special no reason for that, it's probably of a
simple mistake of not including the return of php_file_le_pstream() in the
list of accepted resource types.


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

Bug #52827 [PATCH]: cURL leaks handle and causes assertion error (CURLOPT_STDERR)

[cataphr...@php.net]

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

 ID: 52827
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:cURL leaks handle and causes assertion error
 (CURLOPT_STDERR)
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Lenny x64; Windows 7 x64
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: curlopt_stderr_with_test
Revision:   1284403798
URL:   
http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr_with_test&revision=1284403798


Previous Comments:

[2010-09-13 16:56:01] cataphr...@php.net

The following patch has been added/updated:

Patch Name: curlopt_stderr
Revision:   1284389761
URL:   
http://bugs.php.net/patch-display.php?bug=52827&patch=curlopt_stderr&revision=1284389761


[2010-09-13 16:55:39] cataphr...@php.net

Description:

curl_setopt, when given a stream with CURLOPT_STDERR, stores the zval*
and increments both the refcount of the zval* and of the resource.



Only the refcount of the zval should be incremented.



Additionally, due to a flaw in the streams API, this leak results in an
assertion error. The reason is that on shutdown the unexposed/leaked
resources are destroyed in reverse order, so the encapsulated STDIO
stream is destroyed first and when the TEMP stream is destroyed, it then
tries to close the encapsulated STDIO steam again. I will submit this as
a separate bug report.

Test script:
---
http://www.example.com');

curl_setopt($handle, CURLOPT_STDERR, $s);

Expected result:

No output.

Actual result:
--
(with stream debug)



stream_alloc: TEMP:0x12a61b0 persistent=(null)

stream_alloc: MEMORY:0x12a6488 persistent=(null)

stream_alloc: STDIO:0x12a6f90 persistent=(null)

stream_free: MEMORY:0x12a6488[(null)] in_free=0 opts=0003

stream_free: MEMORY:0x12a6488[(null)] preserve_handle=0 release_cast=1
remove_rs  rc=1

stream_free: MEMORY:0x12a6488[(null)] in_free=1 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] in_free=0 opts=000b

stream_free: STDIO:0x12a6f90[/tmp/phpghmjqQ] preserve_handle=0
release_cast=1 re  move_rsrc=1

/tmp/php-5.3.3/main/streams/streams.c(400) : Stream of type 'STDIO'
0x12a6f90 (p  ath:/tmp/phpghmjqQ) was not closed

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] in_free=0
opts=000b

stream_free: TEMP:0x12a61b0[php://temp/maxmemory=1024] preserve_handle=0
release  _cast=1 remove_rsrc=1

php: /tmp/php-5.3.3/main/streams/plain_wrapper.c:434: php_stdiop_flush:
Assertio  n `data != ((void *)0)' failed.

Aborted







#0  0x7f74b5a22ed5 in raise () from /lib/libc.so.6

#1  0x7f74b5a243f3 in abort () from /lib/libc.so.6

#2  0x7f74b5a1bdc9 in __assert_fail () from /lib/libc.so.6

#3  0x0076129e in php_stdiop_flush (stream=0x1049dc8)

at /tmp/php-5.3.3/main/streams/plain_wrapper.c:434

#4  0x007596dd in _php_stream_flush (stream=0x1049dc8,
closing=0)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#5  0x0075df57 in php_stream_temp_flush (stream=0x1049050)

at /tmp/php-5.3.3/main/streams/memory.c:440

#6  0x007596dd in _php_stream_flush (stream=0x1049050,
closing=1)

at /tmp/php-5.3.3/main/streams/streams.c:1050

#7  0x00757b4d in _php_stream_free (stream=0x1049050,
close_options=11)

at /tmp/php-5.3.3/main/streams/streams.c:331

#8  0x0075a831 in stream_resource_regular_dtor (rsrc=0x104ab48)

at /tmp/php-5.3.3/main/streams/streams.c:1426

#9  0x007c4f9e in list_entry_destructor (ptr=0x104ab48)

at /tmp/php-5.3.3/Zend/zend_list.c:184

#10 0x007c249d in zend_hash_apply_deleter (ht=0xe0c650,
p=0x1049198)

at /tmp/php-5.3.3/Zend/zend_hash.c:611

#11 0x007c25ff in zend_hash_graceful_reverse_destroy
(ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_hash.c:646

#12 0x007c510f in zend_destroy_rsrc_list (ht=0xe0c650)

at /tmp/php-5.3.3/Zend/zend_list.c:240

#13 0x007b1549 in zend_deactivate () at
/tmp/php-5.3.3/Zend/zend.c:896

#14 0x0073e71b in php_request_shutdown (dummy=0x0)

at /tmp/php-5.3.3/main/main.c:1633

#15 0x00899a12 in main (argc=2, argv=0x7fffea5acfa8)

at /tmp/php-5.3.3/sapi/cli/php_cli.c:1373








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

[PHP-BUG] Req #52860 [NEW]: htmlspecialchars/htmlentities stripping invalid characters

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  trunk-SVN-2010-09-16 (SVN)
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:htmlspecialchars/htmlentities stripping invalid characters

Description:

htmlspecialchars() and htmlentities() are commonly used to convert
user-supplied text into text that's safe to output in an HTML or XML
document.



Actually, they are insufficient for this purpose, because characters that
are invalid in XML or XHTML are not stripped out.



In HTML, this results in an invalid document.



In XML, the result is worse because one will end-up with malformed XML.
Therefore, sanitation with htmlspecialchars can result in corrupted data.



Additionaly, when passed $double_encode == true, invalid character entities
(i.e. those which refer to invalid characters) should also be stripped
out.



See

* http://www.w3.org/TR/REC-xml/#NT-Char

* http://www.w3.org/TR/REC-xml/#NT-CharRef

Test script:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>



Test







%s





XML;

}

elseif ($mode == "html") {

header("Content-type: text/html; charset=utf-8");

$templ = <





Test





%s





HTML;

}

else die("bad mode");



$data = "My data: <\x1F";



echo sprintf($templ, htmlentities($data, ENT_NOQUOTES, "UTF-8"));

Expected result:

At minimum, this should be documented in the manual pages for
htmlspecialchars and htmlentities.



A better solution would be to change those two functions to strip
characters outside the allowed range:



#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]



Another alternative, which wouldn't break BC, would be to add another
function or another flag to htmlentities/htmlspecialchars (in addition to
ENT_NOQUOTES/ENT_QUOTES/ENT_COMPAT) that would strip out these characters,
possible plus those that authors are "encouraged to avoid":



[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],

[#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3],

[#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6],

[#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9],

[#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC],

[#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF],

[#x10FFFE-#x10].





Actual result:
--
The W3C validator gives an error:



You have used an illegal character in your text. HTML uses the standard
UNICODE Consortium character repertoire, and it leaves undefined (among
others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive)
that are sometimes used for typographical quote marks and similar in
proprietary character sets. The validator has found one of these undefined
characters in your document. The character may appear on your browser as a
curly quote, or a trademark symbol, or some other fancy glyph; on a
different computer, however, it will likely appear as a completely
different character, or nothing at all.





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

Bug #52863 [Com]: PHP Crash - RAM consuming

[cataphr...@php.net]

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

 ID: 52863
 Comment by: cataphr...@php.net
 Reported by:g dot delaportas at gmail dot com
 Summary:PHP Crash - RAM consuming
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows 7
 PHP Version:Irrelevant
 Block user comment: N

 New Comment:

Did actually crash? Can you provide a backtrace? It's normal it consumes
all the RAM (if you have no memory limit), since you are allocating
memory recursively and indefinitely.


Previous Comments:

[2010-09-16 18:16:47] g dot delaportas at gmail dot com

Description:

I use only native PHP code with no extra plugins loaded.

The PHP 5.3.1 crashes and consumes all the RAM when I use the script
below.

This also happens to all the versions after 5.3.1.



Test script:
---
class Test_Crash

{

private $virtual_func;   

public function __construct()

{

$this->virtual_func = new Test_Crash;

}

}









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

[PHP-BUG] Req #52874 [NEW]: Refactor big if condition w/ collateral effects and nested ternary statements

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  trunk-SVN-2010-09-18 (SVN)
Package:  Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Refactor big if condition w/ collateral effects and nested 
ternary statements

Description:

Two if conditions (one in zend_std_read_property and another in
zend_std_write_property) are very confusing and should be refactored.
Here's one:



493 if (EXPECTED(property_info != NULL) &&

494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0) &&

495  property_info->offset >= 0) ?

496 (zobj->properties ?

497 ((variable_ptr =
(zval**)zobj->properties_table[property_info->offset]) != NULL) :

498 (*(variable_ptr =
&zobj->properties_table[property_info->offset]) != NULL)) :

499 (EXPECTED(zobj->properties != NULL) &&

500   EXPECTED(zend_hash_quick_find(zobj->properties,
property_info->name, property_info->name_length+1, property_info->h, (void
**) &variable_ptr) == SUCCESS {

501 /* if we already have this value there, we don't 
actually need to
do anything */



This is very non-obvious.



I've refactored the conditions, which I tested with no regressions in the
tests.


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

Req #52874 [PATCH]: Refactor big if condition w/ collateral effects and nested ternary statements

[cataphr...@php.net]

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

 ID: 52874
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Refactor big if condition w/ collateral effects and
 nested ternary statements
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:trunk-SVN-2010-09-18 (SVN)
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: refact_if
Revision:   1284773271
URL:   
http://bugs.php.net/patch-display.php?bug=52874&patch=refact_if&revision=1284773271


Previous Comments:

[2010-09-18 03:27:28] cataphr...@php.net

Description:

Two if conditions (one in zend_std_read_property and another in
zend_std_write_property) are very confusing and should be refactored.
Here's one:



493 if (EXPECTED(property_info != NULL) &&

494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0)
&&

495  property_info->offset >= 0) ?

496 (zobj->properties ?

497 ((variable_ptr =
(zval**)zobj->properties_table[property_info->offset]) != NULL) :

498 (*(variable_ptr =
&zobj->properties_table[property_info->offset]) != NULL)) :

499 (EXPECTED(zobj->properties != NULL) &&

500   EXPECTED(zend_hash_quick_find(zobj->properties,
property_info->name, property_info->name_length+1, property_info->h,
(void **) &variable_ptr) == SUCCESS {

501 /* if we already have this value there, we don't 
actually need
to do anything */



This is very non-obvious.



I've refactored the conditions, which I tested with no regressions in
the tests.







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

Req #52874 [Com]: Refactor big if condition w/ collateral effects and nested ternary statements

[cataphr...@php.net]

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

 ID: 52874
 Comment by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Refactor big if condition w/ collateral effects and
 nested ternary statements
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:trunk-SVN-2010-09-18 (SVN)
 Block user comment: N

 New Comment:

It's not just non-obvious. It also makes debugging harder. If I segfault
on the if condition, my debugger will show it as occurring in the last
line of the if.


Previous Comments:

[2010-09-18 03:27:51] cataphr...@php.net

The following patch has been added/updated:

Patch Name: refact_if
Revision:   1284773271
URL:   
http://bugs.php.net/patch-display.php?bug=52874&patch=refact_if&revision=1284773271


[2010-09-18 03:27:28] cataphr...@php.net

Description:

Two if conditions (one in zend_std_read_property and another in
zend_std_write_property) are very confusing and should be refactored.
Here's one:



493 if (EXPECTED(property_info != NULL) &&

494 ((EXPECTED((property_info->flags & ZEND_ACC_STATIC) == 0)
&&

495  property_info->offset >= 0) ?

496 (zobj->properties ?

497 ((variable_ptr =
(zval**)zobj->properties_table[property_info->offset]) != NULL) :

498 (*(variable_ptr =
&zobj->properties_table[property_info->offset]) != NULL)) :

499 (EXPECTED(zobj->properties != NULL) &&

500   EXPECTED(zend_hash_quick_find(zobj->properties,
property_info->name, property_info->name_length+1, property_info->h,
(void **) &variable_ptr) == SUCCESS {

501 /* if we already have this value there, we don't 
actually need
to do anything */



This is very non-obvious.



I've refactored the conditions, which I tested with no regressions in
the tests.







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

Req #52860 [Com]: htmlspecialchars/htmlentities stripping invalid characters

[cataphr...@php.net]

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

 ID: 52860
 Comment by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:htmlspecialchars/htmlentities stripping invalid
 characters
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Irrelevant
 PHP Version:trunk-SVN-2010-09-16 (SVN)
 Block user comment: N

 New Comment:

HTML5 follows the same direction:



8.1.4 Character references

[...]

The numeric character reference forms described above are allowed to
reference any Unicode code point other than U+, U+000D, permanently
undefined Unicode characters (noncharacters), and control characters
other than space characters.



8.2.2.3 Preprocessing the input stream

[...]

All U+ NULL characters and code points in the range U+D800 to U+DFFF
in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs. Any
occurrences of such characters and code points are parse errors.



Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E
to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B,
U+FFFE, U+, U+1FFFE, U+1, U+2FFFE, U+2, U+3FFFE, U+3,
U+4FFFE, U+4, U+5FFFE, U+5, U+6FFFE, U+6, U+7FFFE, U+7,
U+8FFFE, U+8, U+9FFFE, U+9, U+AFFFE, U+A, U+BFFFE, U+B,
U+CFFFE, U+C, U+DFFFE, U+D, U+EFFFE, U+E, U+E, U+F,
U+10FFFE, and U+10 are parse errors. These are all control
characters or permanently undefined Unicode characters (noncharacters).


Previous Comments:

[2010-09-16 16:45:10] cataphr...@php.net

Where it says "invalid in XML or XHTML are not stripped out" it should
read "invalid in XML or HTML are not stripped out". The characters are
also invalid in HTML.

----
[2010-09-16 13:57:42] cataphr...@php.net

Description:

htmlspecialchars() and htmlentities() are commonly used to convert
user-supplied text into text that's safe to output in an HTML or XML
document.



Actually, they are insufficient for this purpose, because characters
that are invalid in XML or XHTML are not stripped out.



In HTML, this results in an invalid document.



In XML, the result is worse because one will end-up with malformed XML.
Therefore, sanitation with htmlspecialchars can result in corrupted
data.



Additionaly, when passed $double_encode == true, invalid character
entities (i.e. those which refer to invalid characters) should also be
stripped out.



See

* http://www.w3.org/TR/REC-xml/#NT-Char

* http://www.w3.org/TR/REC-xml/#NT-CharRef

Test script:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>



Test







%s





XML;

}

elseif ($mode == "html") {

header("Content-type: text/html; charset=utf-8");

$templ = <<http://www.w3.org/TR/html4/loose.dtd";>





Test





%s





HTML;

}

else die("bad mode");



$data = "My data: <\x1F";



echo sprintf($templ, htmlentities($data, ENT_NOQUOTES, "UTF-8"));

Expected result:

At minimum, this should be documented in the manual pages for
htmlspecialchars and htmlentities.



A better solution would be to change those two functions to strip
characters outside the allowed range:



#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10]



Another alternative, which wouldn't break BC, would be to add another
function or another flag to htmlentities/htmlspecialchars (in addition
to ENT_NOQUOTES/ENT_QUOTES/ENT_COMPAT) that would strip out these
characters, possible plus those that authors are "encouraged to avoid":



[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],

[#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3],

[#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6],

[#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9],

[#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC],

[#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF],

[#x10FFFE-#x10].





Actual result:
--
The W3C validator gives an error:



You have used an illegal character in your text. HTML uses the standard
UNICODE Consortium character repertoire, and it leaves undefined (among
others) 65 character codes (0 to 31 inclusive and 127 to 159 inclusive)
that are sometimes used for typographical quote marks and similar in
proprietary character sets. The validator has found one of these
undefined characters in your document. The character may appear on your
browser as a curly quote, or a trademark symbol, or some other fancy
glyph; on a different computer, however, it will likely appear as a
completely different character, or nothing at all.

Bug #52906 [PATCH]: gmp_mod returns negative result when non-negative is expected

[cataphr...@php.net]

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

 ID: 52906
 Patch added by: cataphr...@php.net
 Reported by:kkcagg at gmail dot com
 Summary:gmp_mod returns negative result when non-negative is
 expected
 Status: Analyzed
 Type:   Bug
 Package:GNU MP related
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: gmp_mod
Revision:   1285170233
URL:   
http://bugs.php.net/patch-display.php?bug=52906&patch=gmp_mod&revision=1285170233


Previous Comments:

[2010-09-22 17:21:09] cataphr...@php.net

This is a bug in the PHP extension. Worse, the result differs if you
pass a GMP resource instead of an integer:



$ php -r "echo gmp_intval(gmp_mod(-2, gmp_add(6,1)));"

5



The problem is that gmp_zval_binary_ui_op_ex changes the sign of the
result if it uses the unsigned integer variant of the GMP API and the
first operand is negative. This may be the correct for other binary
functions (I haven't checked), but it isn't for mod.





The documentation mirrors the upstream documentation, which says:



«

— Function: void mpz_mod (mpz_t r, mpz_t n, mpz_t d)

— Function: unsigned long int mpz_mod_ui (mpz_t r, mpz_t n, unsigned
long int d)



Set r to n mod d. The sign of the divisor is ignored; the result is
always non-negative.

»



http://gmplib.org/manual/Integer-Division.html#Integer-Division


[2010-09-22 11:48:29] kkcagg at gmail dot com

Description:

GMP version 4.2.2



Running the function in test script returns the output of -5 when 5 is
expected.

Documentation (http://us.php.net/manual/en/function.gmp-mod.php) asserts
that the 

result is always non-negative. This is not the case in actuality. Bug
type could 

be either a bug or documentation problem.

Test script:
---


Expected result:

5

Actual result:
--
-5






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

Bug #52926 [PATCH]: stream_context_set_default() does not work as intended with stream chaining

[cataphr...@php.net]

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

 ID: 52926
 Patch added by: cataphr...@php.net
 Reported by:simast at gmail dot com
 Summary:stream_context_set_default() does not work as
 intended with stream chaining
 Status: Analyzed
 Type:   Bug
 Package:Zlib Related
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: zlib_inner_open
Revision:   1285530552
URL:   
http://bugs.php.net/patch-display.php?bug=52926&patch=zlib_inner_open&revision=1285530552


Previous Comments:

[2010-09-26 21:48:49] cataphr...@php.net

Fixed in attached patch.



The problem is php_stream_gzopen doesn't forward the context when
opening the inner stream; this isn't limited to default contexts.


[2010-09-26 15:07:20] simast at gmail dot com

Description:

Hello!



I was trying to add gzip/deflate support to standard HTTP streams (code
attached). 

It seems stream_context_set_default() works fine as long as stream
wrappers are 

not chained, like when used with "compress.zlib://" it will not use
options as set 

with this function and will revert to php default ones.



Simas

Test script:
---
stream_context_set_default(array(



'http' => array(

'protocol_version' => 1.1, // HTTP 1.1 compatible

'header' => array(

'Connection: close', // No Keep-Alive

'Accept-Encoding: gzip, deflate' // We support content 
compression

)

)

));



file_get_contents('compress.zlib://http://example.com');

Expected result:

Default stream options should be used for chained streams as well.







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

[PHP-BUG] Bug #52939 [NEW]: zend_call_function does not respect ZEND_SEND_PREFER_REF

[cataphr...@php.net]

From: cataphract
Operating system: Windows 7 x64
PHP version:  trunk-SVN-2010-09-28 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:zend_call_function does not respect ZEND_SEND_PREFER_REF

Description:

The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it
were ZEND_SEND_BY_REF.

Test script:
---
refcount__gc);

php_var_dump(params[i], 0 TSRMLS_CC);

}

efree(params);

}



ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3)

ZEND_ARG_INFO(0, req_pass_by_val)

ZEND_ARG_INFO(1, req_pass_by_ref)

ZEND_ARG_INFO(2, req_prefer_ pass_by_ref)

ZEND_END_ARG_INFO()

Expected result:

Both calls would be successful.

Actual result:
--
Only the direct call is successful:



direct call

[0x5ddbed0, refcount=1] int(1)

[0x5ddc530, refcount=2] &string(1) "a"

[0x5ddbf20, refcount=1] int(7)

call via zend_call_function

PHP Warning:  Parameter 3 to test_passing() expected to be a reference,
value gi

ven in - on line 12

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

Bug #52939 [PATCH]: zend_call_function does not respect ZEND_SEND_PREFER_REF

[cataphr...@php.net]

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

 ID: 52939
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:zend_call_function does not respect
 ZEND_SEND_PREFER_REF
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:trunk-SVN-2010-09-28 (SVN)
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: zend_call_user_function_prefer_ref
Revision:   1285638612
URL:   
http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285638612


Previous Comments:

[2010-09-28 03:44:24] cataphr...@php.net

Description:

The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it
were ZEND_SEND_BY_REF.

Test script:
---
refcount__gc);

php_var_dump(params[i], 0 TSRMLS_CC);

}

efree(params);

}



ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3)

ZEND_ARG_INFO(0, req_pass_by_val)

ZEND_ARG_INFO(1, req_pass_by_ref)

ZEND_ARG_INFO(2, req_prefer_ pass_by_ref)

ZEND_END_ARG_INFO()

Expected result:

Both calls would be successful.

Actual result:
--
Only the direct call is successful:



direct call

[0x5ddbed0, refcount=1] int(1)

[0x5ddc530, refcount=2] &string(1) "a"

[0x5ddbf20, refcount=1] int(7)

call via zend_call_function

PHP Warning:  Parameter 3 to test_passing() expected to be a reference,
value gi

ven in - on line 12






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

Bug #52939 [PATCH]: zend_call_function does not respect ZEND_SEND_PREFER_REF

[cataphr...@php.net]

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

 ID: 52939
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:zend_call_function does not respect
 ZEND_SEND_PREFER_REF
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:trunk-SVN-2010-09-28 (SVN)
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: zend_call_user_function_prefer_ref
Revision:   1285639039
URL:   
http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285639039


Previous Comments:

[2010-09-28 03:50:12] cataphr...@php.net

The following patch has been added/updated:

Patch Name: zend_call_user_function_prefer_ref
Revision:   1285638612
URL:   
http://bugs.php.net/patch-display.php?bug=52939&patch=zend_call_user_function_prefer_ref&revision=1285638612


[2010-09-28 03:44:24] cataphr...@php.net

Description:

The function zend_call_function interprets ZEND_SEND_PREFER_REF as if it
were ZEND_SEND_BY_REF.

Test script:
---
refcount__gc);

php_var_dump(params[i], 0 TSRMLS_CC);

}

efree(params);

}



ZEND_BEGIN_ARG_INFO_EX(arginfo_test_passing, 0, 0, 3)

ZEND_ARG_INFO(0, req_pass_by_val)

ZEND_ARG_INFO(1, req_pass_by_ref)

ZEND_ARG_INFO(2, req_prefer_ pass_by_ref)

ZEND_END_ARG_INFO()

Expected result:

Both calls would be successful.

Actual result:
--
Only the direct call is successful:



direct call

[0x5ddbed0, refcount=1] int(1)

[0x5ddc530, refcount=2] &string(1) "a"

[0x5ddbf20, refcount=1] int(7)

call via zend_call_function

PHP Warning:  Parameter 3 to test_passing() expected to be a reference,
value gi

ven in - on line 12






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

[PHP-BUG] Bug #52940 [NEW]: call_user_func_array still allows call-time pass-by-reference

[cataphr...@php.net]

From: cataphract
Operating system: Windows 7 x64; Debian Lenny x64
PHP version:  trunk-SVN-2010-09-28 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:call_user_func_array still allows call-time pass-by-reference

Description:

zend_call_function does not properly convert references into
non-references, hence allowing passing by reference arguments to functions
that expect values.



See also bug #43484.



This is harder to do with internal function because there's currently a
variable separation for those. However, it's still not impossible, because
if I'm not mistaken there are ways to make the engine give you a variable
with is_ref = 1, refcount  <= 1.



I propose making the behavior for internal functions consistent with that
of user functions by separating the variable all time if it's a reference
and the parameter is to be sent by value; for cases where is_ref = 1,
refcount <= 1, the reference flag should be cleared.

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

Bug #52940 [PATCH]: call_user_func_array still allows call-time pass-by-reference

[cataphr...@php.net]

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

 ID: 52940
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:call_user_func_array still allows call-time
 pass-by-reference
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64; Debian Lenny x64
 PHP Version:trunk-SVN-2010-09-28 (SVN)
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: no_call_time_pass_by_ref_via_ZCF
Revision:   1285649367
URL:   
http://bugs.php.net/patch-display.php?bug=52940&patch=no_call_time_pass_by_ref_via_ZCF&revision=1285649367


Previous Comments:

[2010-09-28 04:53:54] cataphr...@php.net

Description:

zend_call_function does not properly convert references into
non-references, hence allowing passing by reference arguments to
functions that expect values.



See also bug #43484.



This is harder to do with internal function because there's currently a
variable separation for those. However, it's still not impossible,
because if I'm not mistaken there are ways to make the engine give you a
variable with is_ref = 1, refcount  <= 1.



I propose making the behavior for internal functions consistent with
that of user functions by separating the variable all time if it's a
reference and the parameter is to be sent by value; for cases where
is_ref = 1, refcount <= 1, the reference flag should be cleared.

Test script:
---
http://bugs.php.net/bug.php?id=52940&edit=1

Bug #52944 [PATCH]: fclose: quiet script interruption

[cataphr...@php.net]

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

 ID: 52944
 Patch added by: cataphr...@php.net
 Reported by:svimik at mail dot ru
 Summary:fclose: quiet script interruption
 Status: Verified
 Type:   Bug
 Package:*Network Functions
 Operating System:   Debian-50-lenny-64
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: zlib_filter_segfault_fix
Revision:   1285725279
URL:   
http://bugs.php.net/patch-display.php?bug=52944&patch=zlib_filter_segfault_fix&revision=1285725279


Previous Comments:

[2010-09-28 22:10:55] cataphr...@php.net

Valgrind log for trunk:



http://nebm.ist.utl.pt/~glopes/valgrind-52944.log


[2010-09-28 21:58:55] cataphr...@php.net

I can confirm some sort of bug in both PHP 5.3.3 and trunk on Debian
Lenny x64.



On trunk:



[Tue Sep 28 20:54:06 2010]  Script:  '-'

---

/tmp/trunk/ext/zlib/zlib_filter.c(165) : Block 0x7fba5a6120c0 status:

Beginning:  OK (allocated on /tmp/trunk/ext/zlib/zlib_filter.c:311,
2048 bytes)

Start:  OK

  End:  Overflown (magic=0x0018 instead of 0x5289A744)

At least 4 bytes overflown

---

done

[Tue Sep 28 20:54:06 2010]  Script:  '-'

/tmp/trunk/ext/zlib/zlib_filter.c(311) :  Freeing 0x7FBA5A6120C0 (2048
bytes), script=-

=== Total 1 memory leaks detected ===



On PHP 5.3.3 (sorry, not debug build), there's a segfault:



#0  zend_mm_remove_from_free_list (heap=0x11fc290, mm_block=0x1407380)

at /opt/php-5.3.3/Zend/zend_alloc.c:841

#1  0x0069613e in _zend_mm_free_int (heap=0x11fc290,
p=0x1406b80)

at /opt/php-5.3.3/Zend/zend_alloc.c:2019

#2  0x7f029fa548c9 in php_zlib_inflate_dtor (

thisfilter=)

at /opt/php-5.3.3/ext/zlib/zlib_filter.c:161

#3  0x00678ae2 in php_stream_filter_free (filter=0x1409950)

at /opt/php-5.3.3/main/streams/filter.c:312

#4  0x00678b8a in php_stream_filter_remove (filter=0x0,
call_dtor=1)

at /opt/php-5.3.3/main/streams/filter.c:531

#5  0x0067559a in _php_stream_free (stream=0x14096a0,
close_options=11)

at /opt/php-5.3.3/main/streams/streams.c:369

#6  0x006757d1 in stream_resource_regular_dtor (

rsrc=) at
/opt/php-5.3.3/main/streams/streams.c:1426

#7  0x006c34a2 in list_entry_destructor (ptr=0x14097e0)

at /opt/php-5.3.3/Zend/zend_list.c:184

#8  0x006c2566 in zend_hash_del_key_or_index (ht=0xc6e7b0,
arKey=0x0,

nKeyLength=0, h=2, flag=)

at /opt/php-5.3.3/Zend/zend_hash.c:497

#9  0x006c3719 in _zend_list_delete (id=)

at /opt/php-5.3.3/Zend/zend_list.c:58

#10 0x005fbd88 in zif_fclose (ht=,

return_value=0x1409228, return_value_ptr=,

this_ptr=, return_value_used=)

at /opt/php-5.3.3/ext/standard/file.c:928

#11 0x00704cce in zend_do_fcall_common_helper_SPEC (

execute_data=0x7f029f9ce050) at
/opt/php-5.3.3/Zend/zend_vm_execute.h:316

#12 0x006e0589 in execute (op_array=0x14067c8)

at /opt/php-5.3.3/Zend/zend_vm_execute.h:107

#13 0x006b349b in zend_execute_scripts (type=8, retval=0x0,

file_count=3) at /opt/php-5.3.3/Zend/zend.c:1194

#14 0x0065e5e8 in php_execute_script
(primary_file=0x7fff04d51350)

at /opt/php-5.3.3/main/main.c:2260

#15 0x00740717 in main (argc=1, argv=0x7fff04d515b8)

at /opt/php-5.3.3/sapi/cli/php_cli.c:1192


[2010-09-28 21:40:50] svimik at mail dot ru

Description:

Don't know exactly, is it bug in zlib filter or in streams, but this
combination can produce a script crash without any error output.



Lets take some binary data like corrupted compressed data (not every
random data produce crash, so try file from my example). Use
stream_socket_pair with zlib.inflate filter on the second socket, which
is used for reading in my case.

Use non-blocking streams.

Then make exactly following sequence to produce crash:

1. write corrupted data to socket 0

2. call fread for socket 1 (returns nothing as expected, because string
cannot be uncompressed)

3. call fclose for socket 0

4. try fread for socket 1 once again

5. call fclose for socket 1 - on this step scrips dies.



Sorry, can't make a backtrace on a production server, because it is
necessary to recompile the php. Waiting for someone to confirm the bug.

Test script:
---
http://188.40.74.4/corrupted.gz";);

$out="";



fwrite($sockets[0], $in);

$out.=fread($sockets[1], 1);

fclose($sockets[0]);

$out.=fread($sockets[1], 1);



echo "closing...";

fclose($sockets[1])

Bug #51986 [PATCH]: array_filter breaks references when a callback is used

[cataphr...@php.net]

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

 ID: 51986
 Patch added by: cataphr...@php.net
 Reported by:daniel dot menard at ehesp dot fr
 Summary:array_filter breaks references when a callback is
 used
 Status: Analyzed
 Type:   Bug
 Package:Arrays related
 Operating System:   Windows XP
 PHP Version:5.3.2
 Assigned To:dmitry
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug_51986_5_3
Revision:   1285794735
URL:   
http://bugs.php.net/patch-display.php?bug=51986&patch=bug_51986_5_3&revision=1285794735


Previous Comments:

[2010-09-29 23:11:41] cataphr...@php.net

Sorry, it doesn't work on trunk, it works on my patched trunk :p



Fixing bug #52940 would fix this. However, the patch for that bug has
one effect that changes the current behavior of call_user_func_array
(removes check for internal function) and another change when the
refcount of the zval is <= 1 and it's a reference (a rare case).



Attached a patch that changes as little as possible, yet fixes this bug.

----
[2010-09-29 13:05:51] cataphr...@php.net

Reproducible on PHP 5.3, but not on trunk.


[2010-06-03 14:29:38] daniel dot menard at ehesp dot fr

Thanks for your comment: your workaround works.



However, having to redefine standard php functions like trim() or
count() just to be able to use them with array_filter() is not very
convenient, is it?



The fact is that the function behaviour changed in a "revision release"
which should not have broken my code...  



;-)


[2010-06-03 13:00:43] sjo...@php.net

Use a reference in your callback function:



function my_trim(& $a)

{

return trim($a);

}


[2010-06-03 12:28:24] daniel dot menard at ehesp dot fr

Description:

I have an array and a variable which is a reference on some element in
this array:

$arr=array('a'); $ref = &$arr[0]



If I apply array_filter() with a callback like trim() or count() on the
array, the reference is broken and $ref is no longer a reference (If I
apply array_filter() without a callback, the reference is not altered
and the result is correct).



I think that this is a regression introduced in php 5.2.11: with the
test script below, 5.2.10 give the good result, 5.2.11 do not.



I also tested with the latest version (5.3.2): same result, reference is
broken.



PS: I tested on windows XP with packages php-5.x.y-Win32-VC6-x86.zip
provided on this page:
http://windows.php.net/downloads/releases/archives/

Test script:
---
// Init

$arr = array('some value');

$ref = & $arr[0];



// Change $arr

$arr[0] = 'ONE';

echo 'step 1. $ref is ', ($ref !== 'ONE') ? 'BROKEN' : 'OK', "\n";



// Apply array_filter (without callback) and change $arr

array_filter($arr);

$arr[0] = 'TWO';

echo 'step 2. $ref is ', ($ref !== 'TWO') ? 'BROKEN' : 'OK', "\n";



// Apply array_filter (with a callback) then change $arr

array_filter($arr,'trim');

$arr[0] = 'THREE';

echo 'step 3. $ref is ', ($ref !== 'THREE') ? 'BROKEN' : 'OK', "\n";

Expected result:

step 1. $ref is OK

step 2. $ref is OK

step 3. $ref is OK

Actual result:
--
step 1. $ref is OK

step 2. $ref is OK

step 3. $ref is BROKEN






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

[PHP-BUG] Bug #53012 [NEW]: On shared module unload: Unloading DLL containing an active critical section.

[cataphr...@php.net]

From: cataphract
Operating system: Vista amd64
PHP version:  trunk-SVN-2010-10-07 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:On shared module unload: Unloading DLL containing an active 
critical section.

Description:

When running PHP with App verifier, there's an exception on module unload.

Test script:
---
This happens with an empty script

Expected result:

No exception.

Actual result:
--
CommandLine:
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php.exe

Symbol search path is:
SRV*C:\Users\Cataphract\AppData\Local\SYMBOLS*http://msdl.microsoft.com/download/symbols

Executable search path is: 

ModLoad: `0040 `00421000   php.exe 

ModLoad: `7795 `77ad6000   ntdll.dll

ModLoad: `77b1 `77c7   ntdll32.dll

ModLoad: `7526 `752a5000  
C:\Windows\system32\wow64.dll

ModLoad: `7521 `7525e000  
C:\Windows\system32\wow64win.dll

ModLoad: `753e `753e9000  
C:\Windows\system32\wow64cpu.dll

(2e40.3150): Break instruction exception - code 8003 (first chance)

ntdll!DbgBreakPoint:

`77996060 cc  int 3

0:000> g

ModLoad: `7732 `7744d000   WOW64_IMAGE_SECTION

ModLoad: `76a4 `76b5   WOW64_IMAGE_SECTION

ModLoad: `7732 `7744d000   NOT_AN_IMAGE

ModLoad: `7725 `7731d000   NOT_AN_IMAGE

ModLoad: `71ab `71ae1000  
C:\Windows\syswow64\verifier.dll

Page heap: pid 0x2E40: page heap enabled with flags 0x3.

AVRF: php.exe: pid 0x2E40: flags 0x80C43027: application verifier enabled

ModLoad: `7213 `72159000  
C:\Windows\SysWOW64\vrfcore.dll

ModLoad: `7190 `71951000  
C:\Windows\SysWOW64\vfbasics.dll

ModLoad: `76a4 `76b5  
C:\Windows\syswow64\kernel32.dll

ModLoad: `1000 `106b9000  
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php5ts_debug.dll

ModLoad: `76f2 `77065000  
C:\Windows\syswow64\ole32.dll

ModLoad: `7714 `771ea000  
C:\Windows\syswow64\msvcrt.dll

ModLoad: `76b5 `76be  
C:\Windows\syswow64\GDI32.dll

ModLoad: `7563 `7570  
C:\Windows\syswow64\USER32.dll

ModLoad: `7707 `77136000  
C:\Windows\syswow64\ADVAPI32.dll

ModLoad: `76e0 `76ef  
C:\Windows\syswow64\RPCRT4.dll

ModLoad: `755a `7560  
C:\Windows\syswow64\Secur32.dll

ModLoad: `76ef `76f1d000  
C:\Windows\syswow64\WS2_32.dll

ModLoad: `77ae `77ae6000   C:\Windows\syswow64\NSI.dll

ModLoad: `74ce `74d0c000  
C:\Windows\SysWOW64\DNSAPI.dll

ModLoad: `7198 `71aa4000  
C:\Windows\WinSxS\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_2a4cbfc25558bcd3\MSVCR90D.dll

(2e40.3150): WOW64 breakpoint - code 401f (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

ntdll32!DbgBreakPoint:

77b20004 cc  int 3

0:000:x86> g

ModLoad: 771f 7725   C:\Windows\SysWOW64\IMM32.DLL

ModLoad: 75ba 75c68000   C:\Windows\syswow64\MSCTF.dll

ModLoad: 76df 76df9000   C:\Windows\syswow64\LPK.DLL

ModLoad: 75eb 75f2d000   C:\Windows\syswow64\USP10.dll

ModLoad: 751d 7520b000   C:\Windows\SysWOW64\rsaenh.dll

ModLoad: 74d7 74d8e000   C:\Windows\SysWOW64\USERENV.dll

ModLoad: 01d3 01d96000  
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\php_intl.dll

ModLoad: 4a80 4a925000  
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icuuc42.dll

ModLoad: 4ad0 4bc48000  
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icudt42.dll

ModLoad: 7135 713f3000  
C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb\MSVCR90.dll

ModLoad: 712c 7134e000  
C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb\MSVCP90.dll

ModLoad: 06c1 06d69000  
C:\Users\Cataphract\Documents\SDK\php54dev\vc9\x86\php54-trunk\Debug_TS\icuin42.dll





===

VERIFIER STOP 0201: pid 0x2E40: Unloading DLL containing an active
critical section. 



4A91D150 : Critical section address.

00C418C0 : Critical section initialization stack trace.

04F56FE8 : DLL name address.

4A80 : DLL base address.





===

This verifier stop is continuable.

After debugging it use `go' to continue.



===



(2e40.3150): WOW64 breakpoint - code 401f (first 

[PHP-BUG] Bug #53013 [NEW]: Memory leak detected when compiled with --enable-crt-debug

[cataphr...@php.net]

From: cataphract
Operating system: Vista amd64
PHP version:  trunk-SVN-2010-10-07 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Memory leak detected when compiled with --enable-crt-debug

Description:

An empty script causes a memory leak that is detected when PHP is compiled
with --enable-crt-debug.

Test script:
---
This happens with an empty script.

Actual result:
--
Detected memory leaks!

Dumping objects ->

#File Error#(641) : {7774} normal block at 0x09CECFF0, 6 bytes long.

 Data:  70 74 5F 50 54 00

Object dump complete.

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

Req #44164 [Com]: Handle "Content-Length" HTTP header when zlib.output_compression active

[cataphr...@php.net]

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

 ID: 44164
 Comment by: cataphr...@php.net
 Reported by:mplomer at gmx dot de
 Summary:Handle "Content-Length" HTTP header when
 zlib.output_compression active
 Status: Assigned
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.2.5
 Assigned To:cataphract
 Block user comment: N

 New Comment:

I've just been hit by this problem and I'm thinking a better option
would be to disable zlib.output_compression if the Content-Length header
is set. What do you think?



Buffering everything and then calculating the actual length is not
really an option, the output could be several hundred megabytes.


Previous Comments:

[2008-02-19 11:04:24] mplomer at gmx dot de

Another idea is:

IF the Content-Length header IS set from the script,

THEN buffer the complete output and calculate the correct compressed
Content-Length.

ELSE do nothing (do not add any Content-Length header)



So ob_flush(), flush() will still work if compression is active. (Which
will not work, if we use apache's mod_deflate. This is why
"zlib.output_compression" is required.)


[2008-02-19 10:48:09] mplomer at gmx dot de

Description:

If you have a big project, where "Content-Length" header is set on many
places, and then you turn on "zlib.output_compression", you will have a
problem, because the original header is still passed through, but it is
invalid now, because it contains the length of the uncompressed data
instead of the compressed data.

This would confuse some HTTP clients, that rely on the
"Content-Length".

I think, "zlib.output_compression" should be completely transparent, so
this issue should be handled in php core.

One solution is, to remove the "Content-Length" header (if set) in
ob_gzhandler() in ext/zlib/zlib.c:882 (where "Content-Encoding: gzip"
header is set). If you see a good way to set the Content-Length to the
compressed length, this would be, of course, the best solution, but this
is IMHO only possible, if the entire data is buffered before (or is this
done by ob_gzhandler anyway?).

This would make the various workarounds irrelevant that have to be done
if "zlib.output_compression" is active and is completely backward
compatible.

Reproduce code:
---
In php.ini:

zlib.output_compression = On







Expected result:

Correct "Content-Length" header or removed "Content-Length" header in
response, because the old length is always wrong. Better send no
"Content-Length" instead a wrong length.

Actual result:
--
The old "Content-Length" header is sent.






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

[PHP-BUG] Bug #53153 [NEW]: Memory leak with phpinfo() + output buffering + zlib compression

[cataphr...@php.net]

From: cataphract
Operating system: Windows 7 x64
PHP version:  trunk-SVN-2010-10-25 (SVN)
Package:  Output Control
Bug Type: Bug
Bug description:Memory leak with phpinfo() + output buffering + zlib compression

Description:

There is a memory leak on memory allocated on \main\output.c(809):



if ((handler->buffer.size - handler->buffer.used) <= buf->used) 
{

size_t grow_int = 
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);

size_t grow_buf = 
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));

size_t grow_max = MAX(grow_int, grow_buf);



handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */

handler->buffer.size += grow_max;

}







phpinfo() code:



/* Andale!  Andale!  Yee-Hah! */

php_output_start_default(TSRMLS_C);

php_print_info(flag TSRMLS_CC);

php_output_end(TSRMLS_C);

Test script:
---
File file.php

---

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

Bug #53153 [Com]: Memory leak with phpinfo() + output buffering + zlib compression

[cataphr...@php.net]

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

 ID: 53153
 Comment by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Memory leak with phpinfo() + output buffering + zlib
 compression
 Status: Open
 Type:   Bug
 Package:Output Control
 Operating System:   Windows 7 x64
 PHP Version:trunk-SVN-2010-10-25 (SVN)
 Block user comment: N

 New Comment:

Note: there seems to be no leak if the environment variables
HTTP_ACCEPT_ENCODING actually triggers the zlib compression.


Previous Comments:

[2010-10-25 19:26:56] cataphr...@php.net

Interestingly there's also some corrupted/uninitialized memory in the
memory leak message:



[Mon Oct 25 18:19:39 2010]  Script: 
'z8↔▄¥▄¥¥?d╔�...@Ç

☺'

c:\users\cataphract\documents\php-src\main\output.c(809) :  Freeing
0x012B0088 (

49152 bytes), script=z8↔▄¥▄¥¥?d╔�...@Ç☺

=== Total 1 memory leaks detected ===


[2010-10-25 19:25:44] cataphr...@php.net

Description:

There is a memory leak on memory allocated on \main\output.c(809):



if ((handler->buffer.size - handler->buffer.used) <= buf->used) 
{

size_t grow_int = 
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);

size_t grow_buf = 
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));

size_t grow_max = MAX(grow_int, grow_buf);



handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */

handler->buffer.size += grow_max;

}







phpinfo() code:



/* Andale!  Andale!  Yee-Hah! */

php_output_start_default(TSRMLS_C);

php_print_info(flag TSRMLS_CC);

php_output_end(TSRMLS_C);

Test script:
---
File file.php

---

http://bugs.php.net/bug.php?id=53153&edit=1

[PHP-BUG] Bug #53172 [NEW]: ZEND_ACC_IMPLICIT_PUBLIC should be removed or used in zend_get_property_info

[cataphr...@php.net]

From: cataphract
Operating system: 
PHP version:  5.3SVN-2010-10-26 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:ZEND_ACC_IMPLICIT_PUBLIC should be removed or used in 
zend_get_property_info

Description:

The status of the flag ZEND_ACC_IMPLICIT_PUBLIC is somewhat unclear. In the
ZE:



* PHP 5.3 checks for it in a few places, but doesn't set it anymore as the
body of zend_do_declare_implicit_property is commented out.

* trunk retains only the definition of ZEND_ACC_IMPLICIT_PUBLIC, everything
else is gone.



So it seems that the flag ZEND_ACC_IMPLICIT_PUBLIC, apparently originally
used to signal dynamic properties, is only used by the reflection
extension. The reflection extension, not being able to depend on the Zend
Engine to set it, sets the flag itself when it finds a dynamic property,
i.e. a property that is in the object hash table but has no property_info
(ReflectionProperty::__construct and ReflectionClass::getProperty).



This would be unnecessary if zend_get_property_info set the flag
ZEND_ACC_IMPLICIT_PUBLIC over here:



http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_object_handlers.c#310



In that case, the reflection extension could just call
zend_get_property_info and not do directly lookups in ce->properties_info.
Though right now it would be possible to call zend_get_property_info and
check for equality to &EG(property_info), this is suboptimal.


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

Bug #53199 [PATCH]: Phar doesn't work with '--enable-zend-multibyte' option

[cataphr...@php.net]

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

 ID: 53199
 Patch added by: cataphr...@php.net
 Reported by:brt dot river at gmail dot com
 Summary:Phar doesn't work with '--enable-zend-multibyte'
 option
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   Mac OS X 10.6
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug53199.patch
Revision:   1290066459
URL:   
http://bugs.php.net/patch-display.php?bug=53199&patch=bug53199.patch&revision=1290066459


Previous Comments:

[2010-11-18 07:02:28] php at group dot apple dot com

I have been debugging a similar report with the phar CLI. Executing "php
phar.php" 

(using the generated php/ext/phar/phar.php) works properly, but the
resulting 

phar.phar does not. I have tried modifying the stub (via phar.php) to
print 

debugging information but that only produces more "?" characters.
Attempting to 

debug with Xdebug and MacGDBp wouldn't step through the first line
before 

terminating.


[2010-10-29 10:22:36] brt dot river at gmail dot com

Description:

I'm using PHP 5.3.3 with '--enable-zend-multibyte' under Mac OS X.

My script calls my phar archive directly, The result characters are
garbled.



Test script:
---
* create.php

setStub('http://bugs.php.net/bug.php?id=53199&edit=1

Bug #53465 [PATCH]: Cannot open file descriptor streams

[cataphr...@php.net]

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

 ID: 53465
 Patch added by: cataphr...@php.net
 Reported by:dchurch at sciencelogic dot com
 Summary:Cannot open file descriptor streams
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: php_fd_open.diff
Revision:   1291674246
URL:   
http://bugs.php.net/patch-display.php?bug=53465&patch=php_fd_open.diff&revision=1291674246


Previous Comments:

[2010-12-03 18:24:11] dchurch at sciencelogic dot com

Description:

PHP cannot open, read from, or write to arbitrary file descriptors, a
feature that is necessary for communications with certain utilities that
expect input or output on certain file descriptors.  When programming in
C, this functionality is provided by fdopen().  A feature request was
filed over seven years ago for PHP to have a similar capability through
the php:// stream wrapper (#26158), but the bug was marked as bogus for
no adequately defined reason.



The alternative to being able to use a fdopen()-like function is to open
the file descriptor as a named file through /dev/fd/ or /proc/self/fd/. 
This works in C using fopen("/dev/fd/", "w"), but it does
not work in PHP because PHP incorrectly attempts to dereference the
pseudo-symlink before opening it.



I have a C program and a PHP script that both attempt to do the same
thing: open file descriptor 3 for writing using /dev/fd/3, read until
EOF from standard in and write to the file descriptor.  Both should be
run as:



(executable) 3>&1 | cat

Test script:
---
PHP script:





int main() {

  char buf[8192];

  int count;

  FILE *file;



  file = fopen("/dev/fd/3", "w");



  if (file == NULL) {

perror("Opening /dev/fd/3");

return 1;

  }



  while ((count = fread(buf, 1, sizeof(buf), stdin)) > 0) {

fwrite(buf, count, 1, file);

if (feof(stdin)) break;

  }

  return 0;

}

Expected result:

Input should be mirrored to file descriptor 3; when called using the
command line above, it should be mirrored to standard output.

Actual result:
--
I get the following warning:



PHP Warning:  fopen(/dev/fd/3): failed to open stream: No such file or
directory in test.php on line 2



An strace of the PHP process shows the incorrect behavior:



lstat("/dev/fd/3", {st_mode=S_IFLNK|0300, st_size=64, ...}) = 0

readlink("/dev/fd/3", "pipe:[637257]", 4096) = 13

lstat("/dev/fd/pipe:[637257]", 0x7fff76ae8140) = -1 ENOENT (No such file
or directory)

lstat("/dev/fd", {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0

readlink("/dev/fd", "/proc/self/fd"..., 4096) = 13

lstat("/proc/self/fd", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0

lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=64, ...}) = 0

readlink("/proc/self", "28234"..., 4096) = 5

lstat("/proc/28234", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0

lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0

open("/proc/28234/fd/pipe:[637257]", O_WRONLY|O_CREAT|O_TRUNC, 0666) =
-1 ENOENT (No such file or directory)








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

Bug #54440 [PATCH]: stream_context_set_default() should publish the default context to everybody

[cataphr...@php.net]

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

 ID: 54440
 Patch added by: cataphr...@php.net
 Reported by:jpa...@php.net
 Summary:stream_context_set_default() should publish the
 default context to everybody
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   *nix
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: libxslt_54440.patch
Revision:   1301869965
URL:   
http://bugs.php.net/patch-display.php?bug=54440&patch=libxslt_54440.patch&revision=1301869965


Previous Comments:

[2011-04-01 11:45:40] jpa...@php.net

See also #52926


[2011-04-01 11:43:32] jpa...@php.net

Description:

stream_context_set_default() doesn't publish the context to all PHP
extension.



Example is ext/libxml that doesn't recognize the context.

Test script:
---
stream_context_set_default(array('http'=>array('proxy'=>'my_proxy_url')));



$x = simplexml_load_file('http://some_resource');

Expected result:

The resource gets loaded through the HTTP proxy

Actual result:
--
The resource is not loaded through the HTTP proxy.

For this to work, we have to use :



$ctx =
stream_context_create(array('http'=>array('proxy'=>'my_proxy_url')));

libxml_set_streams_context($ctx); // userland manual bind



$x = simplexml_load_file('http://some_resource');






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

Bug #54547 [PATCH]: wrong equality of string numbers

[cataphr...@php.net]

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

 ID: 54547
 Patch added by: cataphr...@php.net
 Reported by:peter dot ritt at gmx dot net
 Summary:wrong equality of string numbers
 Status: Verified
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug54547.diff
Revision:   1302998399
URL:   
http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547.diff&revision=1302998399


Previous Comments:

[2011-04-16 20:07:43] peter dot ritt at gmx dot net

Description:

comparison of strings using == shows wrong results when both strings are
numbers (digits) around PHP_MAX_INT;

the same comparison using === works correctly;

tested on 64 bit systems only, affects also PHP 5.3.5

Test script:
---
$a = '9223372036854775807';

$b = '9223372036854775808';

if ($a == $b) {

echo "$a == $b\n";

}

else {

echo "$a != $b\n";

}

// displays 9223372036854775807 == 9223372036854775808



Expected result:

should display

9223372036854775807 != 9223372036854775808

Actual result:
--
displays

9223372036854775807 == 9223372036854775808






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

Bug #54547 [PATCH]: wrong equality of string numbers

[cataphr...@php.net]

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

 ID: 54547
 Patch added by: cataphr...@php.net
 Reported by:peter dot ritt at gmx dot net
 Summary:wrong equality of string numbers
 Status: Verified
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   linux
 PHP Version:5.3.6
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug54547-2.diff
Revision:   1303011843
URL:   
http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547-2.diff&revision=1303011843


Previous Comments:

[2011-04-17 01:59:59] cataphr...@php.net

The following patch has been added/updated:

Patch Name: bug54547.diff
Revision:   1302998399
URL:   
http://bugs.php.net/patch-display.php?bug=54547&patch=bug54547.diff&revision=1302998399


[2011-04-16 20:07:43] peter dot ritt at gmx dot net

Description:

comparison of strings using == shows wrong results when both strings are
numbers (digits) around PHP_MAX_INT;

the same comparison using === works correctly;

tested on 64 bit systems only, affects also PHP 5.3.5

Test script:
---
$a = '9223372036854775807';

$b = '9223372036854775808';

if ($a == $b) {

echo "$a == $b\n";

}

else {

echo "$a != $b\n";

}

// displays 9223372036854775807 == 9223372036854775808



Expected result:

should display

9223372036854775807 != 9223372036854775808

Actual result:
--
displays

9223372036854775807 == 9223372036854775808






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

Bug #54580 [PATCH]: get_browser() segmentation fault

[cataphr...@php.net]

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

 ID: 54580
 Patch added by: cataphr...@php.net
 Reported by:tomas dot brastavicius at quantum dot lt
 Summary:get_browser() segmentation fault
 Status: Assigned
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Ubuntu 10.10 (x86_64)
 PHP Version:trunk-SVN-2011-04-20 (SVN)
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: browscap.diff
Revision:   1303783306
URL:   
http://bugs.php.net/patch-display.php?bug=54580&patch=browscap.diff&revision=1303783306


Previous Comments:

[2011-04-21 13:54:12] cataphr...@php.net

The problem is not ini_set, the segault occurs because PHP assumes the
parse result of the code is initialized when the ini setting is
non-empty; however, by using php_admin_value, the ini setting value is
set after when the parsing code runs, so when it runs it leaves memory
initialized because the ini setting is empty.



This should be fixed by having the ini setting change via
php_admin_value trigger the ini reading and structure initialization.


[2011-04-21 00:06:11] tomas dot brastavicius at quantum dot lt

Description:

PHP is running as an Apache module. The following configuration was used
to compile PHP:

./configure --with-apxs2=/usr/bin/apxs2 --enable-debug --disable-all

Test script:
---
1. Be sure browscap directive is commented out in php.ini

2. Set browscap setting in Apache configuration file, i.e.
php_admin_value browscap "/some/path/browscap.ini"

3. Run the following PHP script:

arBuckets[nIndex];



Full backtrace:



#0  0x709db2af in zend_hash_find (ht=0x70e6e100, 

arKey=0x77f6b760 "User-Agent", nKeyLength=109,
pData=0x7fffbdb8)

at /a/php-trunk/Zend/zend_hash.c:905

#1  0x708ac3b1 in zif_get_browser (ht=0,
return_value=0x77f62be8, return_value_ptr=0x0, 

this_ptr=0x0, return_value_used=1) at
/a/php-trunk/ext/standard/browscap.c:360

#2  0x70a09972 in zend_do_fcall_common_helper_SPEC
(execute_data=0x77f2e338)

at /a/php-trunk/Zend/zend_vm_execute.h:642

#3  0x70a0ffd2 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x77f2e338)

at /a/php-trunk/Zend/zend_vm_execute.h:1963

#4  0x70a08077 in execute (op_array=0x77f611c0)

at /a/php-trunk/Zend/zend_vm_execute.h:410

#5  0x709c88a3 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)

at /a/php-trunk/Zend/zend.c:1212

#6  0x70933982 in php_execute_script
(primary_file=0x7fffe670)

at /a/php-trunk/main/main.c:2349

#7  0x70b0de48 in php_handler (r=0x784bbea0)

at /a/php-trunk/sapi/apache2handler/sapi_apache2.c:667

#8  0x77fd6310 in ap_run_handler (r=0x784bbea0) at
/build/buildd/apache2-2.2.16/server/config.c:159

#9  0x77fd9c9e in ap_invoke_handler (r=0x784bbea0)

at /build/buildd/apache2-2.2.16/server/config.c:377

#10 0x77fe77b8 in ap_process_request (r=0x784bbea0)

at /build/buildd/apache2-2.2.16/modules/http/http_request.c:282

#11 0x77fe4748 in ap_process_http_connection (c=0x784adc90)

at /build/buildd/apache2-2.2.16/modules/http/http_core.c:190

#12 0x77fddef8 in ap_run_process_connection (c=0x784adc90)

at /build/buildd/apache2-2.2.16/server/connection.c:43

#13 0x77fec177 in child_main (child_num_arg=)

at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:662

#14 0x77fec446 in make_child (s=0x78214938, slot=0)

at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:702

#15 0x77feca93 in ap_mpm_run (_pconf=,
plog=, 

s=) at
/build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:978

#16 0x77fc2530 in main (argc=2, argv=0x7fffecf8) at
/build/buildd/apache2-2.2.16/server/main.c:742






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

[PHP-BUG] Bug #54657 [NEW]: Function parameters can no longer be named after superglobal variables

[cataphr...@php.net]

From: cataphract
Operating system: Any
PHP version:  trunk-SVN-2011-05-04 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Function parameters can no longer be named after superglobal 
variables

Description:

There is a backwards incompatible change in trunk in that function can no
longer have parameters with a name equal to the one of some superglobal.



This should either be fixed with the previous behavior (the parameter
shadows the superglobal) or documented in UPGRADING.

Test script:
---
$ php -d error_reporting=-1

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

[PHP-BUG] Bug #60007 [NEW]: comparison function is not anticommutative for arrays claimed to be comparable

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  trunk-SVN-2011-06-29 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:comparison function is not anticommutative for arrays claimed 
to be comparable

Description:

This discussion is limited to the subsets of the array domain with elements
that the manual claims are comparable between each other:
«Array with fewer members is smaller, if key from operand 1 is not found
in operand 2 then arrays are uncomparable, otherwise - compare value by
value»
http://docs.php.net/manual/en/language.operators.comparison.php
Whether the relations should be total (or partial) orders in the entire
array domain is beyond the scope of this bug report.

The comparison function used to compare arrays with the operators, <, <=,
>, >= is not anticommutative, i.e., swapping the arguments doesn't change
the sign. It should be the case that

cmp(a, b) = - cmp(b, a)

The reason for this is that the relations <, <=, >, >=  should be
antisymmetric, i.e., R(a, b) and R(b, a) cannot both be true unless maybe a
== b (in which case the relation is reflexive, as is the case of <= and
>=).

The relationship between the comparison function and the relations easily
follows by how the relations are defined:
a < b  === cmp(a,b) == -1
a <= b === cmp(a,b) <= 0
a > b  === cmp(b,a) == -1
a >= b === cmp(b,a) <= 0

It is important that the relations are antisymmetric because it's a
requirement for relation to be a total (or even partial!) order. Without
that property, it's impossible to, for instance, reliably sort or do a
binary search in an array of arrays.

The problem is the comparison function is sensitive to the order of the
arguments. It starts by comparing the value of the first element of the
first operand with the corresponding (i.e., with the same key) element in
the second operand. One can see that, for any two arrays with the same
length and keys, if reset($a) < $b[key($a)] && reset($b) < $x[key($a)],
then $a < $b and $b < $a.

References:
http://en.wikipedia.org/wiki/Anticommutativity
http://en.wikipedia.org/wiki/Antisymmetric_relation
http://en.wikipedia.org/wiki/Reflexive_relation
http://en.wikipedia.org/wiki/Total_order
http://stackoverflow.com/questions/6480365/comparing-arrays-in-php-interesting-behaviour/6481181#6481181

Test script:
---
 1, "b" => 2);
$a = array("b" => 1, "a" => 2);
var_dump($a < $b);
var_dump($b < $a);
var_dump($b > $a);
var_dump($a > $b);


Expected result:

bool(true)   //or false
bool(false)  //or true
bool(true)   //or false
bool(false)  //or true

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


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

Bug #55305 [PATCH]: ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating

[cataphr...@php.net]

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

 ID: 55305
 Patch added by: cataphr...@php.net
 Reported by:yaa...@php.net
 Summary:ref lost: 1st ref instantiated in class def, 2nd ref
 made w/o instantiating
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   ALL
 PHP Version:5.4SVN-2011-07-27 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug55305.patch
Revision:   1311813002
URL:
https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813002


Previous Comments:

[2011-07-27 23:32:55] yaa...@php.net

Description:

Reference is lost, causing segfault and/or oddities when primary reference is 
edited after secondary is edited.

Occurs only when the variable name is instantiated in the class definition, and 
the second reference is not instantiated before it is made. Possible 
workarounds 
include:

Instantiate neither variable name in the class definition
Instantiate both variable names in the class definition
Instantiate secondary variable name before making it a reference to the first:
  $this->bar = nil;
  $this->bar =& $this->foo;

The bug is new to 5.4.

Test script:
---
foo = '';
$this->bar =& $this->foo;
  }
  function dump(){
echo 'foo: ';var_dump($this->foo);
echo 'bar: ';var_dump($this->bar);
  }
}

$f = new Foo();
$f->dump();
$f->foo .= 'foo';
$f->dump();
$f->bar .= 'bar';
$f->dump();
$f->foo .= 'foo';
$f->dump();
?>

Expected result:

foo: string(0) ""
bar: string(0) ""
foo: string(3) "bar"
bar: string(3) "bar"
foo: string(6) "barfoo"
bar: string(6) "barfoo"


Actual result:
--
varies from platform to platform

On Windows:

foo: string(0) ""
bar: NULL
foo: string(3) "foo"
bar: NULL
foo: UNKNOWN:0
bar: string(3) "bar"
CRASH

On Linux (Ubuntu 11.04):

foo: string(0) ""
bar: NULL
foo: NULL
bar: string(3) "bar" 
foo: string(3) "foo"
bar: string(3) "???"

where ?? is 3 seemingly-random bytes.

OR, if an additional one-or-three-parameter method is defined in the class 
(even 
if it is not called):

string(0) ""
NULL
NULL
Segmentation fault

If the uncalled method has a different number of arguments, it generates a 
zend_mm_heap_corrupted instead






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

Bug #55305 [PATCH]: ref lost: 1st ref instantiated in class def, 2nd ref made w/o instantiating

[cataphr...@php.net]

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

 ID: 55305
 Patch added by: cataphr...@php.net
 Reported by:yaa...@php.net
 Summary:ref lost: 1st ref instantiated in class def, 2nd ref
 made w/o instantiating
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   ALL
 PHP Version:5.4SVN-2011-07-27 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug55305.patch
Revision:   1311813005
URL:
https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813005


Previous Comments:

[2011-07-28 00:30:02] cataphr...@php.net

The following patch has been added/updated:

Patch Name: bug55305.patch
Revision:   1311813002
URL:
https://bugs.php.net/patch-display.php?bug=55305&patch=bug55305.patch&revision=1311813002


[2011-07-27 23:32:55] yaa...@php.net

Description:

Reference is lost, causing segfault and/or oddities when primary reference is 
edited after secondary is edited.

Occurs only when the variable name is instantiated in the class definition, and 
the second reference is not instantiated before it is made. Possible 
workarounds 
include:

Instantiate neither variable name in the class definition
Instantiate both variable names in the class definition
Instantiate secondary variable name before making it a reference to the first:
  $this->bar = nil;
  $this->bar =& $this->foo;

The bug is new to 5.4.

Test script:
---
foo = '';
$this->bar =& $this->foo;
  }
  function dump(){
echo 'foo: ';var_dump($this->foo);
echo 'bar: ';var_dump($this->bar);
  }
}

$f = new Foo();
$f->dump();
$f->foo .= 'foo';
$f->dump();
$f->bar .= 'bar';
$f->dump();
$f->foo .= 'foo';
$f->dump();
?>

Expected result:

foo: string(0) ""
bar: string(0) ""
foo: string(3) "bar"
bar: string(3) "bar"
foo: string(6) "barfoo"
bar: string(6) "barfoo"


Actual result:
--
varies from platform to platform

On Windows:

foo: string(0) ""
bar: NULL
foo: string(3) "foo"
bar: NULL
foo: UNKNOWN:0
bar: string(3) "bar"
CRASH

On Linux (Ubuntu 11.04):

foo: string(0) ""
bar: NULL
foo: NULL
bar: string(3) "bar" 
foo: string(3) "foo"
bar: string(3) "???"

where ?? is 3 seemingly-random bytes.

OR, if an additional one-or-three-parameter method is defined in the class 
(even 
if it is not called):

string(0) ""
NULL
NULL
Segmentation fault

If the uncalled method has a different number of arguments, it generates a 
zend_mm_heap_corrupted instead






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

[PHP-BUG] Bug #55326 [NEW]: Trait method copying misindentifies serialization callbacks

[cataphr...@php.net]

From: cataphract
Operating system: Irrelevant
PHP version:  trunk-SVN-2011-07-31 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Trait method copying misindentifies serialization callbacks

Description:

_ADD_MAGIC_METHOD in zend_compile.c identifies "serialize_func" and
"unserialize_func" as magic methods and copies them to ce->serialize_func
and ce->unserialize_func.

The correct names are "serialize" and "unserialize". These names could be
changed, or, better yet, those two lines should be deleted because the
methods serialize and unserialize are only relevant if the class implements
Serializable (or, more precisely, if ce->serialize and ce->unserialize are
zend_user_serialize and zend_user_unserialize, respectively, and in any
case ce->serialize_func and ce->unserialize_func work only as a lazy cache.

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

Bug #55326 [PATCH]: Trait method copying misindentifies serialization callbacks

[cataphr...@php.net]

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

 ID: 55326
 Patch added by: cataphr...@php.net
 Reported by:cataphr...@php.net
 Summary:Trait method copying misindentifies serialization
 callbacks
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:trunk-SVN-2011-07-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug55326.diff
Revision:   1312082252
URL:
https://bugs.php.net/patch-display.php?bug=55326&patch=bug55326.diff&revision=1312082252


Previous Comments:

[2011-07-31 03:16:48] cataphr...@php.net

Description:

_ADD_MAGIC_METHOD in zend_compile.c identifies "serialize_func" and 
"unserialize_func" as magic methods and copies them to ce->serialize_func and 
ce->unserialize_func.

The correct names are "serialize" and "unserialize". These names could be 
changed, or, better yet, those two lines should be deleted because the methods 
serialize and unserialize are only relevant if the class implements 
Serializable (or, more precisely, if ce->serialize and ce->unserialize are 
zend_user_serialize and zend_user_unserialize, respectively, and in any case 
ce->serialize_func and ce->unserialize_func work only as a lazy cache.

Test script:
---
https://bugs.php.net/bug.php?id=55326&edit=1

[PHP-BUG] Bug #55797 [NEW]: Integer overflow leads to segfault in SdnToGregorian (in optimized builds)

[cataphr...@php.net]

From: cataphract
Operating system: Linux/gcc
PHP version:  5.3.8
Package:  Date/time related
Bug Type: Bug
Bug description:Integer overflow leads to segfault in SdnToGregorian (in 
optimized builds)

Description:

SdnToGregorian has an integer overflow error.

This has already been fixed; this report is for reference.

See also bug #53574.

Test script:
---
(x86)
php -r 'print_r(cal_from_jd(882858030, CAL_GREGORIAN));

(amd64)
php -r 'print_r(cal_from_jd(9223372036854743639, CAL_GREGORIAN));'

Expected result:

No segfault

Actual result:
--
Segfault

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

Bug #60131 [PATCH]: fopen('php://stdout'...) redirect all posterious echo to /dev/null

[cataphr...@php.net]

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

 ID: 60131
 Patch added by: cataphr...@php.net
 Reported by:frederic dot hardy at mageekbox dot net
 Summary:fopen('php://stdout'...) redirect all posterious
 echo to /dev/null
 Status: Wont fix
 Type:   Bug
 Package:Streams related
 Operating System:   Mac OS Snow Leopard
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug60131.diff
Revision:   131991
URL:
https://bugs.php.net/patch-display.php?bug=60131&patch=bug60131.diff&revision=131991


Previous Comments:

[2011-10-30 03:09:23] cataphr...@php.net

Won't fix since some people rely on this behavior. What happens is the first 
time you fopen stdout, the file descriptor 1 is not duped and exposed with a 
stream, instead the stdlib FILE* is exposed through a stream. When the stream 
is closed, the FILE* is closed too, potentially also closing stdout, i.e., a 
close(1) syscall (which is what happens in your case – since you don't assign 
the return of fopen, the stream is immediately destroyed). Turns out some 
people use this technique to close the standard file descriptors and open 
others (and AFAIK there's no other way to do it in PHP).


[2011-10-25 14:24:53] frederic dot hardy at mageekbox dot net

Description:

If fopen('php://stdout', ...) is used in a php processus open with proc_open(), 
all posterious call to echo or print seems to be redirected to /dev/null.

Test script:
---
 array("pipe", "r"),
   1 => array("pipe", "w")
);

$php = proc_open('php', $descriptors, $pipes);

stream_set_blocking($pipes[1], 0);

fwrite($pipes[0], '');
fclose($pipes[0]);

$null = null;

$select = array($pipes[1]);

while (feof($pipes[1]) === false)
{
if (stream_select($select, $null, $null, null))
{
var_dump(stream_get_contents($pipes[1]));
}
}

Expected result:

foobar

Actual result:
--
foo






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

[PHP-BUG] Bug #60343 [NEW]: nmake clean results in root dir emptied in some cases

[cataphr...@php.net]

From: cataphract
Operating system: Windows
PHP version:  trunk-SVN-2011-11-20 (SVN)
Package:  *Compile Issues
Bug Type: Bug
Bug description:nmake clean results in root dir emptied in some cases

Description:

When running buildconf and configure on the same source directory, but via
different symlinks, the resulting Makefile produces rules that result in
nmake clean causing all the files (but not directories) of the source dir
being deleted.

Actual result:
--
The gist https://gist.github.com/1381227 contains two files.

In the first, both buildconf and configure were run under
C:\Users\Cataphract_\Documents\php-src

In the second, buildconf was run under
C:\Users\Cataphract\Documents\php-src and configure was run under
C:\Users\Cataphract_\Documents\php-src

C:\Users\Cataphract_\Documents\php-src and
C:\Users\Cataphract\Documents\php-src represent the same directory.

nmake clean was run under C:\Users\Cataphract_\Documents\php-src in both
cases.

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

[PHP-BUG] Bug #60373 [NEW]: Startup errors with log_errors on cause segfault

[cataphr...@php.net]

From: cataphract
Operating system: ZTS builds (tested on Win)
PHP version:  trunk-SVN-2011-11-24 (SVN)
Package:  Date/time related
Bug Type: Bug
Bug description:Startup errors with log_errors on cause segfault

Description:

In ZTS builds, when log_errors is on and there are startup errors, PHP
segfaults.

Test script:
---
Load an inexistent extension in php.ini.

Actual result:
--
0:000:x86> kP
ChildEBP RetAddr  
00a1e310 0f880c3f php5ts_debug!guess_timezone(
struct _timelib_tzdb * tzdb = 0x0face790, 
void *** tsrm_ls = 0x010832a0)+0x2d
[c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 841]
00a1e408 0f8810d5 php5ts_debug!get_timezone_info(
void *** tsrm_ls = 0x010832a0)+0x4f
[c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 868]
00a1e504 0f829d2c php5ts_debug!php_format_date(
char * format = 0x0fa759c4 "d-M-Y H:i:s", 
int format_len = 0n11, 
long ts = 0n1322156443, 
int localtime = 0n1, 
void *** tsrm_ls = 0x010832a0)+0x35
[c:\users\cataphract_\documents\php-src\ext\date\php_date.c @ 1118]
00a1e628 0f82f728 php5ts_debug!php_log_err(
char * log_message = 0x011e25a0 "PHP Warning:  PHP 
Startup: Unable to
load dynamic library
'C:\Users\Cataphract_\Documents\php-src\Debug_TS\php_interbase.dll' - The
specified module could not be found... in Unknown on line 0", 
void *** tsrm_ls = 0x010832a0)+0x11c
[c:\users\cataphract_\documents\php-src\main\main.c @ 578]
00a1e7d4 0f694c4d php5ts_debug!php_error_cb(
int type = 0n32, 
char * error_filename = 0x0fa61a90 "Unknown", 
unsigned int error_lineno = 0, 
char * format = 0x0fa61a30 "%s", 
char * args = 0x00a1eaa8 "???")+0x5c8
[c:\users\cataphract_\documents\php-src\main\main.c @ 1005]
00a1ea98 0f82a9a5 php5ts_debug!zend_error(
int type = 0n32, 
char * format = 0x0fa61a30 "%s")+0x24d
[c:\users\cataphract_\documents\php-src\zend\zend.c @ 1082]
00a1ec9c 0f82adf2 php5ts_debug!php_verror(
char * docref = 0x "", 
char * params = 0x0fa618f8 "", 
int type = 0n32, 
char * format = 0x0fb0e104 "Unable to load dynamic 
library '%s' - %s", 
char * args = 0x00a1edac "???", 
void *** tsrm_ls = 0x010832a0)+0x8c5
[c:\users\cataphract_\documents\php-src\main\main.c @ 801]
00a1ed94 0f9be474 php5ts_debug!php_error_docref0(
char * docref = 0x "", 
void *** tsrm_ls = 0x010832a0, 
int type = 0n32, 
char * format = 0x0fb0e104 "Unable to load dynamic 
library '%s' -
%s")+0x42 [c:\users\cataphract_\documents\php-src\main\main.c @ 813]
00a1eef8 0f83dc11 php5ts_debug!php_load_extension(
char * filename = 0x011e20f8 "php_interbase.dll", 
int type = 0n1, 
int start_now = 0n0, 
void *** tsrm_ls = 0x010832a0)+0x1d4
[c:\users\cataphract_\documents\php-src\ext\standard\dl.c @ 149]
00a1efdc 0f7fdef6 php5ts_debug!php_load_php_extension_cb(
void * arg = 0x00f9c218, 
void *** tsrm_ls = 0x010832a0)+0x31
[c:\users\cataphract_\documents\php-src\main\php_ini.c @ 351]
00a1f0c4 0f83db87 php5ts_debug!zend_llist_apply(
struct _zend_llist * l = 0x0fb6a818, 
 * func = 0x0f83dbe0, 
void *** tsrm_ls = 0x010832a0)+0x46
[c:\users\cataphract_\documents\php-src\zend\zend_llist.c @ 193]
00a1f1a4 0f82e3b3 php5ts_debug!php_ini_register_extensions(
void *** tsrm_ls = 0x010832a0)+0x47
[c:\users\cataphract_\documents\php-src\main\php_ini.c @ 747]
00a1f5f0 0130223e php5ts_debug!php_module_startup(
struct _sapi_module_struct * sf = 0x0131f008, 
struct _zend_module_entry * additional_modules = 
0x, 
unsigned int num_additional_modules = 0)+0xc33
[c:\users\cataphract_\documents\php-src\main\main.c @ 2131]
00a1f6d0 01302938 php!php_cli_startup(
struct _sapi_module_struct * sapi_module = 
0x0131f008)+0x2e
[c:\users\cataphract_\documents\php-src\sapi\cli\php_cli.c @ 414]
00a1f8b8 0131718f php!main(
int argc = 0n3, 
char ** argv = 0x01083140)+0x6b8
[c:\users\cataphract_\documents\php-src\sapi\cli\php_cli.c @ 1336]
00a1f908 01316fbf php!__tmainCRTStartup(void)+0x1bf
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe