date:20120416

From: ab
Operating system: windows
PHP version:  5.3.10
Package:  *Directory/Filesystem functions
Bug Type: Bug
Bug description:Tests in ext\standard\tests\file\windows_acls\* fail

Description:

All the three tests

ext\standard\tests\file\windows_acls\bug44859.phpt
ext\standard\tests\file\windows_acls\bug44859_2.phpt 
ext\standard\tests\file\windows_acls\bug44859_4.phpt

are failing for the same reason. When getenv('USERNAME') is empty or icacls
is not in the path.

Expected result:

tests pass

Actual result:
--
tests fail

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

Bug #61743 [PATCH]: Tests in ext\standard\tests\file\windows_acls\* fail

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

 ID: 61743
 Patch added by: a...@php.net
 Reported by:a...@php.net
 Summary:Tests in ext\standard\tests\file\windows_acls\* fail
 Status: Open
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   windows
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

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


Previous Comments:

[2012-04-16 09:35:53] a...@php.net

Description:

All the three tests

ext\standard\tests\file\windows_acls\bug44859.phpt
ext\standard\tests\file\windows_acls\bug44859_2.phpt 
ext\standard\tests\file\windows_acls\bug44859_4.phpt

are failing for the same reason. When getenv('USERNAME') is empty or icacls is 
not in the path.

Expected result:

tests pass

Actual result:
--
tests fail






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

Bug #36226 [Com]: Inconsistent handling when passing potential arrays.

2012-04-16 Thread a at b dot com

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

 ID: 36226
 Comment by: a at b dot com
 Reported by:say_ten at multiplay dot co dot uk
 Summary:Inconsistent handling when passing potential arrays.
 Status: Closed
 Type:   Bug
 Package:SOAP related
 Operating System:   FreeBSD 6.0-p4
 PHP Version:5.1.2
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

@dmitry: Can you explain why you consider inconsistent behaviour a feature?


Previous Comments:

[2007-03-20 07:52:09] dmi...@php.net

Fixed in CVS HEAD and PHP_5_2.


[2007-03-18 10:15:18] lsm...@php.net

Ah ok .. I finally had the genius idea of searching the existing test cases for 
one that covers my issues. Since I am a phpt n00b, I ripped the code instead of 
simply updating the test case. The code should be similar enough for you to 
recognize from the test case for Bug 
#36226.

http://pooteeweet.org/public/SOAP_SINGLE_ELEMENT_ARRAYS.phps

I
 did a minor change to the wsdl to allow nillable for the 
sequence.

http://pooteeweet.org/public/bug35142.wsdl

Would
 be nice to have that one fixed for php 5.2.2.

So the issue 
is that I end up with an array(null) for logOnEvent instead of simply null. 


[2007-02-23 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2007-02-15 15:47:30] dmi...@php.net

Could you please provide a working example with expected output. I cannot 
imagine the situation when ext/soap will return array(null) for unexisting XML 
elements.


[2007-02-08 15:32:19] lsm...@php.net

Enabling this feature seems to result in giving me an array(null) if I have a 
nill'ed sequence. Not sure if this is why you originally introduced the feature 
of not returning single element sequences as array's, but I was hoping to get 
an empty array in the above case.




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

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


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

[PHP-BUG] Bug #61744 [NEW]: preg_match crashes

From: 
Operating system: Win 7 64-bit
PHP version:  5.4.1RC2
Package:  *Regular Expressions
Bug Type: Bug
Bug description:preg_match crashes

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes

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

Bug #61744 [Com]: preg_match crashes

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

 ID: 61744
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Try as Apache module.
php.exe testcase.php does not crash


Previous Comments:

[2012-04-16 10:57:30] bugzilla33 at gmail dot com

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes






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

Bug #61728 [Ver]: PHP crash when calling ob_start in session_write

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

 ID: 61728
 Updated by: larue...@php.net
 Reported by:frederik_php at vanrenterghem dot biz
-Summary:php-fpm SIGSEGV running friendica on nginx
+Summary:PHP crash when calling ob_start in session_write
 Status: Verified
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux Debian Wheezy
 PHP Version:5.4.0
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

change the summary


Previous Comments:

[2012-04-14 17:21:22] larue...@php.net

assign to me, since I have made a try to fix it. will close this after confirm 
that fix is okey.


[2012-04-14 17:18:02] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f
Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx)


[2012-04-14 17:16:58] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f
Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx)


[2012-04-14 16:59:05] larue...@php.net

if you try to start a user output handler in session_write.  then it will 
crash. I 
have attach a simple reproduce script. 

and also made a simple fix.


[2012-04-14 16:58:03] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61728.patch
Revision:   1334422683
URL:
https://bugs.php.net/patch-display.php?bug=61728&patch=bug61728.patch&revision=1334422683




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

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


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

Bug #61743 [Opn->Csd]: Tests in ext\standard\tests\file\windows_acls\* fail

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

 ID: 61743
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:Tests in ext\standard\tests\file\windows_acls\* fail
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-16 09:44:06] a...@php.net

The following patch has been added/updated:

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


[2012-04-16 09:35:53] a...@php.net

Description:

All the three tests

ext\standard\tests\file\windows_acls\bug44859.phpt
ext\standard\tests\file\windows_acls\bug44859_2.phpt 
ext\standard\tests\file\windows_acls\bug44859_4.phpt

are failing for the same reason. When getenv('USERNAME') is empty or icacls is 
not in the path.

Expected result:

tests pass

Actual result:
--
tests fail






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

Bug #61680 [Opn->Csd]: ext\zlib\tests\gzencode_variation1-win32.phpt fails

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

 ID: 61680
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\zlib\tests\gzencode_variation1-win32.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-11 15:07:30] a...@php.net

this test was relying on the bin2hex functionality, which is still broken in 
php 5.3, so just gzdecode the data back, so in the patch


[2012-04-11 15:06:16] a...@php.net

The following patch has been added/updated:

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


[2012-04-09 15:15:43] a...@php.net

Description:

The test diff could be found here:

http://belsky.info/uploads/my/bugz/gzencode_variation1-win32.diff

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61677 [Com]: ext\zlib\tests\bug_52944.phpt fails

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

 ID: 61677
 Comment by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\zlib\tests\bug_52944.phpt fails
 Status: Open
 Type:   Bug
 Package:Zlib related
 Operating System:   all
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

i've just realized, that the output is different on linux ... the thing needs 
probably more investigation


Previous Comments:

[2012-04-09 11:24:35] a...@php.net

zlib doesn't fail anymore on the bug 52944, so the test out is adopted


[2012-04-09 11:23:44] a...@php.net

The following patch has been added/updated:

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


[2012-04-09 11:22:41] a...@php.net

Description:

Test diff:

001+ string(1) "%"
002+ string(1) "C"
001- string(0) ""
002- string(0) ""



Expected result:

test pass

Actual result:
--
test fail






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

Bug #48724 [Opn->Asn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

2012-04-16 Thread tony2001

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

ID: 48724
Updated by: tony2...@php.net
Reported by:an0nym at narod dot ru
Summary:getColumnMeta() doesn't return native_type for BIT,
TINYINT and YEAR
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.3.0
Block user comment: N
Private report: N

New Comment:

Ulf, could you pls check if the attached patch is correct?
Thanks.

Previous Comments:

[2012-04-13 12:06:15] tony2...@php.net

The following patch has been added/updated:

Patch Name: fix-bug-48724.patch
Revision: 1334318775
URL:
https://bugs.php.net/patch-display.php?bug=48724&patch=fix-bug-48724.patch&revision=1334318775

[2009-07-03 16:57:28] u...@php.net

You are free to patch it.

Bye.

[2009-07-03 16:30:12] an0nym at narod dot ru

Poor MySQLi developers... they've managed to solve this problem without
specification.

Poor you... you've spent sooo many time for nothing developing this
function, which works in 35 of 38 cases - this stuff has no
specification! Wait for a specification - you have a good excuse!

Bye.

[2009-07-03 16:17:20] u...@php.net

You are free to write a patch.

I refuse to work on stuff that has no specification and which may go into any
direction. That typically ends up in a backwards compatibility nightmare, which
in particular for an abstraction like PDO makes no sense to me.

The patch may be rather simple. But watch out for different values returned by
different MySQL versions.

[2009-07-03 15:39:20] an0nym at narod dot ru

> libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug.
I agree. This is not a libmysql or mysqlnd bug. This is a PDO (or
PDO_MySQL) bug.

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

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

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

Bug #61716 [Opn->Csd]: tests\basic\021.phpt fails

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

 ID: 61716
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:tests\basic\021.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-13 14:29:15] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 09:20:04] a...@php.net

Description:

Test diff:

001+ Warning: File upload error - unable to create a temporary file in Unknown 
on line 0
007- string(10) "text/plain"
008+ string(0) ""
009- string(%d) "%s"
010+ string(0) ""
012+ int(6)
013+ ["size"]=>
012- ["size"]=>
013- int(9)

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61717 [Opn->Csd]: ext\ldap\tests\ldap_sasl_bind_basic.phpt fails

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

 ID: 61717
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\ldap\tests\ldap_sasl_bind_basic.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:LDAP related
 Operating System:   *
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-13 13:45:39] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 09:35:23] a...@php.net

Description:

Test diff:

001+ Warning: ldap_sasl_bind(): Unable to bind to server: Can't contact LDAP 
server in 
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-r2ca49d3\ext\ldap\tests\ldap_sasl_bind_basic.php
 on line 6
002+ bool(false)
001- bool(true)

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61718 [Opn->Csd]: ext\ldap\tests\ldap_set_rebind_proc_error.phpt fails

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

 ID: 61718
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\ldap\tests\ldap_set_rebind_proc_error.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:LDAP related
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-13 13:46:19] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 13:05:30] a...@php.net

ldap_set_rebind_proc seems not to exist on win


[2012-04-13 13:04:49] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 09:39:14] a...@php.net

Description:

Test diff:

001+ Fatal error: Call to undefined function ldap_set_rebind_proc() in 
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-r2ca49d3\ext\ldap\tests\ldap_set_rebind_proc_error.php
 on line 18
001- Warning: ldap_set_rebind_proc() expects exactly 2 parameters, 1 given in 
%s on line %d
002- bool(false)
003-
004- Warning: ldap_set_rebind_proc() expects exactly 2 parameters, 3 given in 
%s on line %d
005- bool(false)
006-
007- Warning: ldap_set_rebind_proc(): Two arguments expected for 
'rebind_proc_inexistant' to be a valid callback in %s on line %d
008- bool(false)
009- ===DONE===

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61720 [Opn->Csd]: ext\libxml\tests\bug61367-read.phpt fails

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

 ID: 61720
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\libxml\tests\bug61367-read.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*XML functions
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-13 10:58:30] a...@php.net

windows returns backslashes with getcwd(), that's what the error was


[2012-04-13 10:57:35] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 09:46:12] a...@php.net

Description:

Test diff:

006+ Warning: DOMDocument::loadXML(): Invalid URI: 
file:///C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-r2ca49d3\test_bug_61367/bad
 in Entity,
line: 2 in 
C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-r2ca49d3\ext\libxml\tests\bug61367-read.php
 on line 15
006- Warning: DOMDocument::loadXML(): I/O warning : failed to load external 
entity "file:///%s/test_bug_61367/bad" in %s on line %d

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61719 [Opn->Csd]: ext\soap\tests\bugs\bug31422.phpt fails

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

 ID: 61719
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\soap\tests\bugs\bug31422.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SOAP related
 Operating System:   windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-04-13 12:48:58] a...@php.net

the warnings order is differend, so just duplicated for windows


[2012-04-13 12:46:05] a...@php.net

The following patch has been added/updated:

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


[2012-04-13 09:43:26] a...@php.net

Description:

Test diff:

001+ 
002+ http://schemas.xmlsoap.org/soap/envelope/";>SOAP-ENV:ServerHello
003- 
004- http://schemas.xmlsoap.org/soap/envelope/";>SOAP-ENV:ServerHello

Expected result:

test pass

Actual result:
--
test diff






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

Bug #61744 [Opn->Fbk]: preg_match crashes

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

 ID: 61744
 Updated by: larue...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


Previous Comments:

[2012-04-16 11:01:26] bugzilla33 at gmail dot com

Try as Apache module.
php.exe testcase.php does not crash


[2012-04-16 10:57:30] bugzilla33 at gmail dot com

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes






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

[PHP-BUG] Bug #61746 [NEW]: Failing tests in ext/standard/tests/file/windows_links/*

From: ab
Operating system: windows
PHP version:  Irrelevant
Package:  *Directory/Filesystem functions
Bug Type: Bug
Bug description:Failing tests in ext/standard/tests/file/windows_links/*

Description:

The tests failing are:

ext\standard\tests\file\windows_links\bug48746.phpt
ext\standard\tests\file\windows_links\bug48746_1.phpt
ext\standard\tests\file\windows_links\bug48746_2.phpt

The reason is the mountvol not being in the path.

Expected result:

test pass

Actual result:
--
test fail

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

Bug #61744 [Fbk->Opn]: preg_match crashes

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

 ID: 61744
 User updated by:bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.


Previous Comments:

[2012-04-16 14:52:41] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


[2012-04-16 11:01:26] bugzilla33 at gmail dot com

Try as Apache module.
php.exe testcase.php does not crash


[2012-04-16 10:57:30] bugzilla33 at gmail dot com

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes






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

Bug #61744 [Opn]: preg_match crashes

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

 ID: 61744
 Updated by: ras...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?


Previous Comments:

[2012-04-16 16:13:05] bugzilla33 at gmail dot com

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.


[2012-04-16 14:52:41] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


[2012-04-16 11:01:26] bugzilla33 at gmail dot com

Try as Apache module.
php.exe testcase.php does not crash


[2012-04-16 10:57:30] bugzilla33 at gmail dot com

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes






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

Bug #61744 [Opn]: preg_match crashes

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

 ID: 61744
 User updated by:bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site


Previous Comments:

[2012-04-16 16:18:15] ras...@php.net

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?


[2012-04-16 16:13:05] bugzilla33 at gmail dot com

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.


[2012-04-16 14:52:41] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


[2012-04-16 11:01:26] bugzilla33 at gmail dot com

Try as Apache module.
php.exe testcase.php does not crash


[2012-04-16 10:57:30] bugzilla33 at gmail dot com

Description:

preg_match crashes

Test script:
---


Expected result:

preg_match no crash

Actual result:
--
preg_match crashes






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

Bug #61744 [Com]: preg_match crashes

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

 ID: 61744
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10


Previous Comments:

[2012-04-16 16:29:34] bugzilla33 at gmail dot com

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site


[2012-04-16 16:18:15] ras...@php.net

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?


[2012-04-16 16:13:05] bugzilla33 at gmail dot com

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.


[2012-04-16 14:52:41] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit


[2012-04-16 11:01:26] bugzilla33 at gmail dot com

Try as Apache module.
php.exe testcase.php does not crash




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

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


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

Bug #61744 [Com]: preg_match crashes

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

 ID: 61744
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

...and I tested Windows 7 only (32-bit and 64-bit)


Previous Comments:

[2012-04-16 16:31:13] bugzilla33 at gmail dot com

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10


[2012-04-16 16:29:34] bugzilla33 at gmail dot com

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site


[2012-04-16 16:18:15] ras...@php.net

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?


[2012-04-16 16:13:05] bugzilla33 at gmail dot com

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.


[2012-04-16 14:52:41] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I think it is probable because of : 
http://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit




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

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


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

Bug #61744 [Com]: preg_match crashes

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

 ID: 61744
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash


Previous Comments:

[2012-04-16 16:34:13] bugzilla33 at gmail dot com

...and I tested Windows 7 only (32-bit and 64-bit)


[2012-04-16 16:31:13] bugzilla33 at gmail dot com

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10


[2012-04-16 16:29:34] bugzilla33 at gmail dot com

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site


[2012-04-16 16:18:15] ras...@php.net

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?


[2012-04-16 16:13:05] bugzilla33 at gmail dot com

I checked recursion-limit:
pcre.backtrack_limit 100
pcre.recursion_limit 10

On fastCGI or direct php.exe testcase.php does not crash.

When use Apache 2.2.21 with php module with the same php.ini
testcase.php crash apache.

Now I am at home. The same crash like at work - two other machines.




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

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


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

Bug #61743 [Com]: Tests in ext\standard\tests\file\windows_acls\* fail

2012-04-16 Thread mattfic...@php.net

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

 ID: 61743
 Comment by: mattfic...@php.net
 Reported by:a...@php.net
 Summary:Tests in ext\standard\tests\file\windows_acls\* fail
 Status: Closed
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   windows
 PHP Version:5.3.10
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

These tests still fail for me (Windows 7).

%USERNAME% is set and 'icacls' in is my command prompt path.

bug44859.diff:
003+ 
004+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/a.txt):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
005+ 
006+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
004- Iteration #3: passed.
005- Iteration #4: passed.
006- Testing directory:
007- Iteration #1: passed.
008- Iteration #2: passed.
009- Iteration #3: passed.
010- Iteration #4: passed.
008+ 
009+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/a.txt):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
010+ 
011+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
012+ Iteration #3: bool(false)
013+ bool(true)
014+ failed.
015+ 
016+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/a.txt):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
017+ 
018+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
019+ Iteration #4: bool(false)
020+ bool(true)
021+ failed.
022+ 
023+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/a.txt):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
024+ Testing directory:
025+ Iteration #1: passed.
026+ 
027+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/adir):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
028+ 
029+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
030+ Iteration #2: passed.
031+ 
032+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/adir):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
033+ 
034+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
035+ Iteration #3: bool(false)
036+ bool(true)
037+ failed.
038+ 
039+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/adir):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
040+ 
041+ Warning: touch(): Utime failed: Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
042+ Iteration #4: bool(false)
043+ bool(true)
044+ failed.
045+ 
046+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/adir):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132

bug44859_2.diff:
002+ 
003+ Warning: touch(): Utime failed: No such file or directory in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 125
004+ Iteration #1: bool(false)
005+ bool(true)
006+ failed.
007+ 
008+ Warning: 
unlink(C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls/a.txt):
 Permission denied in 
C:\php-sdk\php-test-pack-5.3-nts-windows-vc9-x86-r0f180a6\ext\standard\tests\file\windows_acls\common.inc
 on line 132
009+ 
010+ Warning: touch(): Utime failed: Permission denied i

Bug #61744 [Com]: preg_match crashes

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

 ID: 61744
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 
5.4.0 VC9 Thread Safe

Test script still crashes.


Previous Comments:

[2012-04-16 16:37:16] bugzilla33 at gmail dot com

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash


[2012-04-16 16:34:13] bugzilla33 at gmail dot com

...and I tested Windows 7 only (32-bit and 64-bit)


[2012-04-16 16:31:13] bugzilla33 at gmail dot com

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10


[2012-04-16 16:29:34] bugzilla33 at gmail dot com

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site


[2012-04-16 16:18:15] ras...@php.net

Windows-only, I assume? Apache uses PCRE as well, so perhaps Apache on Windows 
is 
resetting the PCRE limits? I assume it doesn't crash if you reduce the 300 
there 
to something smaller?




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

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


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

Bug #61744 [Opn]: preg_match crashes

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

 ID: 61744
 Updated by: ras...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Are you using mod_security in your Apache?


Previous Comments:

[2012-04-16 16:53:59] bugzilla33 at gmail dot com

Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 
5.4.0 VC9 Thread Safe

Test script still crashes.


[2012-04-16 16:37:16] bugzilla33 at gmail dot com

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash


[2012-04-16 16:34:13] bugzilla33 at gmail dot com

...and I tested Windows 7 only (32-bit and 64-bit)


[2012-04-16 16:31:13] bugzilla33 at gmail dot com

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10


[2012-04-16 16:29:34] bugzilla33 at gmail dot com

str_repeat('AB',200) do not crash

str_repeat('AB',300) crashes - browser freeze about 4sec and info - browser can 
not display site




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

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


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

Bug #61744 [Opn]: preg_match crashes

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

 ID: 61744
 User updated by:bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Open
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

No, I have original httpd.conf from package
and original php.ini-development -> php.ini


Previous Comments:

[2012-04-16 17:12:08] ras...@php.net

Are you using mod_security in your Apache?


[2012-04-16 16:53:59] bugzilla33 at gmail dot com

Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 
5.4.0 VC9 Thread Safe

Test script still crashes.


[2012-04-16 16:37:16] bugzilla33 at gmail dot com

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash


[2012-04-16 16:34:13] bugzilla33 at gmail dot com

...and I tested Windows 7 only (32-bit and 64-bit)


[2012-04-16 16:31:13] bugzilla33 at gmail dot com

...but using apache module phpinfo also says:
pcre.backtrack_limit 100
pcre.recursion_limit 10




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

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


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

Bug #61744 [Opn->Nab]: preg_match crashes

2012-04-16 Thread pajoye

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

 ID: 61744
 Updated by: paj...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

Increase the stack, either using the http configuration or using the 
editbin.exe 
utility.

The stack is overridden by the executable running php, in case of mod_php it is 
apache's.


Previous Comments:

[2012-04-16 17:23:22] bugzilla33 at gmail dot com

No, I have original httpd.conf from package
and original php.ini-development -> php.ini


[2012-04-16 17:12:08] ras...@php.net

Are you using mod_security in your Apache?


[2012-04-16 16:53:59] bugzilla33 at gmail dot com

Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 
5.4.0 VC9 Thread Safe

Test script still crashes.


[2012-04-16 16:37:16] bugzilla33 at gmail dot com

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash


[2012-04-16 16:34:13] bugzilla33 at gmail dot com

...and I tested Windows 7 only (32-bit and 64-bit)




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

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


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

[PHP-BUG] Bug #61747 [NEW]: User-defined error handler run despite at sign (@) error control operator

From: 
Operating system: 
PHP version:  5.4.0
Package:  *General Issues
Bug Type: Bug
Bug description:User-defined error handler run despite at sign (@) error 
control operator

Description:

The at sign operator allows to "ignore" error messages, as explained in
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with
set_error_handler() are nevertheless run when @ is used, which often causes
such messages to show, as in the below example, where a custom error
handler is used to customize the display of error messages.

As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895
and http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042
show, this problem is not new. This behavior appears to be by design, and
might be wanted in some cases.

Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This
needs serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when
suppressing errors.
Make the documentation reflect the current state of things.

Alternatively, if the documentation of the @ operator isn't amended because
custom error handlers are considered a corner case, then the
set_error_handler() documentation should warn developers tempted to use
custom error handlers that they are non-standard, not
recommended/supported, and try to explain the pitfalls. In short, tell
developers they should only use a custom error handler if they know what
they're doing.

However, this alternative should be avoided since set_error_handler() is
already used in several applications whose developers didn't receive the
warning.

Test script:
---
My ERROR [$errno] $errstr\n";
echo "  Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;

case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;

case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;

default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}

// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale =
$scale", E_USER_ERROR);
}

if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected",
E_USER_WARNING);
return null;
}

$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}

return $temp;
}

$a = array(2, 3, "foo", 5.5, 43.3, 21.11);


/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);

set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);

?>


Expected result:

Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42

Call Stack:
0.0005 339192   1. {main}() /var/www/atoperator.php:0
0.0005 339836   2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648   3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42

Actual result:
--
Notice: Value at position 2 is not a number, using 0 (zero) in
/var/www/atoperator.php on line 42

Call Stack:
0.0005 339192   1. {main}() /var/www/atoperator.php:0
0.0005 339836   2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo',
3 => 5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898)
/var/www/atoperator.php:55
0.0006 340648   3. trigger_error('Value at position 2 is not a
number, using 0 (zero)', 1024) /var/www/atoperator.php:42

My NOTICE [1024] Value at position 2 is not a number, using 0
(zero)

-- 
Edit bug report at https://bugs.php.net/bug.php?id=61747&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61747&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61747&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=61747&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61747&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=61747&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61747&r=alreadyfixed
Need bac

Bug #61730 [Fbk->Opn]: Segfault from array_walk modifying an array passed by reference

2012-04-16 Thread joe dot lencioni at gmail dot com

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

 ID: 61730
 User updated by:joe dot lencioni at gmail dot com
 Reported by:joe dot lencioni at gmail dot com
 Summary:Segfault from array_walk modifying an array passed
 by reference
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   2.6.32-131.0.15.el6.x86_64
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

> Does the crash only occur if xdebug is installed?

No, it occurs even if xdebug is not installed. FWIW, it triggers a deprecated 
message: 
"Deprecated: Call-time pass-by-reference has been deprecated"

> Also, can you please generate the backtrace again with the relevant debuginfo 
package installed?

What debuginfo package are you referring to? I may not have the access to do 
that, but 
I'm not entirely sure I understand what you are requesting.


Previous Comments:

[2012-04-14 02:55:51] ahar...@php.net

Does the crash only occur if xdebug is installed?

Also, can you please generate the backtrace again with the relevant debuginfo 
package installed?


[2012-04-13 20:25:07] joe dot lencioni at gmail dot com

Description:

The following code produces a segmentation fault.

Interestingly, if I remove either the unset or the modifying of the array 
values, it 
seems to work fine. Also, this only segfaults when the size of the array is 
larger. At 
1000 or lower, it worked fine.

We are using Xdebug 2.2.0rc1

gdb backtrace:

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/php...(no debugging symbols found)...done.
[New Thread 8825]
Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/libedit.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libedit.so.0
Reading symbols from /lib64/libncurses.so.5...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libncurses.so.5
Reading symbols from /usr/lib64/libgmp.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libgmp.so.3
Reading symbols from /lib64/libbz2.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libbz2.so.1
Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libz.so.1
Reading symbols from /lib64/libpcre.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib64/libpcre.so.0
Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /usr/lib64/libxml2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib64/libkrb5.so.3
Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libk5crypto.so.3
Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libssl.so.10
Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib64/libcrypto.so.10
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libresolv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done.
Loaded symbols for /lib64/libfreebl3.so
Reading symbols from /lib64/libtinfo.so.5...(no debugging symbols found)...done.
Load

Bug #60925 [Opn]: fpm_atomic.h says unknown processor (m68k)

2012-04-16 Thread tg at debian dot org

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

 ID: 60925
 User updated by:tg at debian dot org
 Reported by:tg at debian dot org
 Summary:fpm_atomic.h says unknown processor (m68k)
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
-PHP Version:5.3.9
+PHP Version:5.4
 Block user comment: N
 Private report: N

 New Comment:

Make of this patch what you want. Iâve not gotten anything from the 
Linux/m68k porters other than âwhat do you do if the syscall does not 
exist?â with no solution. (On the other hand, it exists with every Linux 
kernel from 2.6.34 onwards or Debian 2.6.32; and older systems wonât support 
the last few eglibc major releases anyway, so chances are low someoneâs 
trying PHP on such systems. And the patch keeps the #error for non-Linux 
systems.)


Previous Comments:

[2012-03-12 23:31:51] tg at debian dot org

Iâve built 5.4.0 with a small patch. Weâre working on getting it usable for 
upstream inclusion. On Linux/m68k, one uses a syscall for compare-and-swap 32 
bit, as some CPUs do not support the machine instruction and probing for it is 
too tricky in user space. The syscall was introduced along with TLS support, 
now we probably need to safeguard this from being compiled on âtoo oldâ 
Linux systems. The patch doesnât address nÅn-Linux m68k, as those are 
different beasts, and see above. (The ColdFire does not support the 
instruction, and Linux and MiNT may very well both run on one with MMU, 
soonish.)


[2012-02-02 20:11:39] tg at debian dot org

OK; in the meantime Iâll try building without FPM, to see whether there are 
any other lurking issues on m68k. Thanks for the help with this.


[2012-01-31 00:50:00] ahar...@php.net

Thanks again. It's been good to triage this down. :)

I'll let JÃ©rÃ´me figure out what he wants to do here, since he's the FPM 
maintainer. I think your list of options pretty much covers it.


[2012-01-31 00:39:53] tg at debian dot org

Heh, your comment made me go and read the old changelogs
of the Debian package on a guess, and I guessed right:

php5 (5.3.5-1) unstable; urgency=low

   * Build the FPM SAPI (Closes: #603174)

So this was simply never built before. Now there are two
possibilities, disable FPM on m68k (unless gcc-4.7 or up
is used) or ask the m68k porters for an implementation
of the atomic things. I think. If youâve got a better
idea, do tell.

By the way, thereâs libatomic-ops-dev, which contains a
number of atomic primitives and composed operations on a
number of data types (but the catch is, youâve got to use
the data types of libatomic-ops-dev, not e.g. like mesa
have a function atomic_dec which is passed an int32_t*
so itâs not a plug-in replacement. That might be more
interesting than hacking in m68k support now, and support
for $next_arch laterâ¦

m68k atomic operations apparently have another twist: the
compare-and-swap operation only exists on some processors,
and not in the Coldfire line, so the Linux kernel got a
syscall now to ensure atomicity. GCC 4.7 uses the syscall;
most âinlinedâ application code doesnâtâ¦


[2012-01-31 00:06:52] ahar...@php.net

Ah, I didn't know that, so no, no need on the vanilla tarball front. Thanks!

The fix here would be a patch for fpm_atomic.h implementing the same atomic 
functions for m68k as the other fallback platforms in there, such as x86 and 
SPARC 
v9. I'm not actually sure why 5.3.3-7 built at all, actually -- the only patch 
it 
had over stock 5.3.3 (which had no support at all for m68k) was implementing 
support for __sync_bool_compare_and_swap() if it existed, so it should have 
failed 
with the same #error. Interesting.




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

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


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

Req #55815 [Com]: PUT request data should be parsed just like POST

2012-04-16 Thread catch dot dave at gmail dot com

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

 ID: 55815
 Comment by: catch dot dave at gmail dot com
 Reported by:catch dot dave at gmail dot com
 Summary:PUT request data should be parsed just like POST
 Status: Open
 Type:   Feature/Change Request
 Package:Streams related
 Operating System:   All
 PHP Version:5.4.0beta1
 Block user comment: N
 Private report: N

 New Comment:

Hi theanomaly,

I'd like to address your points.

1. As per my original request the manual page of 
"http://php.net/manual/en/features.file-upload.put-
method.php" *does not* solve the problem, as it does not handle multipart form 
requests.

2. Implementing the parsing of multipart form data in PHP seems to be re-
inventing the wheel when the 
code to correctly parse this already exists in PHP itself (to parse POST data).

3. Perhaps I am misunderstanding, but reading through both your quote and the 
rest of the 2616 spec, I 
fail to see how the spec precludes handling form-data in a PUT method, The 
section you quoted is saying 
that:
  * PUT must operate on the URI provided and not another one; and
  * that the difference between PUT and POST, is that POST URI defines the 
resource that operates on 
an entity, whereas a PUT request's URI identifies the entity itself. It is 
common to use the PUT verb to 
operate on existing entities in restful APIs (e.g. modifying the title of an 
existing book, you would send 
the new title as data, and not in the URI itself), which does not seem to 
violate this point either.

The multipart form data is part of the original user request and should 
therefore be parseable--the user 
is sending the data (in multipart form) to operate on the URI using the PUT 
method.

I don't think the spec is saying that you are not allowed to use/consider the 
data sent along with it--
as opposed to your interpretation which suggests the RFC is saying that all 
data 
other than the URI 
itself (whether multipart form encoded or not) should be ignored.

4. I had originally had some code that does exactly what you described, but it 
was nowhere near as 
robust as the existing code in PHP, which lead to me writing this request (re-
invent the wheel). 
Furthermore, other languages (e.g. Ruby) do parse multipart data in PUT (not 
that that should be the 
primary reason).


Previous Comments:

[2012-04-11 01:52:33] theanomaly dot is at gmail dot com

First, I'd like to start by noting that the PHP manual already addresses file 
uploads via PUT method by: 

http://php.net/manual/en/features.file-upload.put-method.php

Second, I want to point out that what you're asking is actually a violation of 
the HTTP specification as per RFC 2616 specifically Section 9.6

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

"The fundamental difference between the POST and PUT requests is reflected in 
the different meaning of the Request-URI. The URI in a POST request identifies 
the resource that will handle the enclosed entity. That resource might be a 
data-accepting process, a gateway to some other protocol, or a separate entity 
that accepts annotations. In contrast, the URI in a PUT request identifies the 
entity enclosed with the request -- the user agent knows what URI is intended 
and the server MUST NOT attempt to apply the request to some other resource. If 
the server desires that the request be applied to a different URI, it MUST send 
a 301 (Moved Permanently) response; the user agent MAY then make its own 
decision regarding whether or not to redirect the request."

What this means is the HTTP RFC does not allow us to identify multipart/form-
data in a PUT request.

Thus your proposed implementation to how PHP already handles requests would 
then 
put PHP in a position of having not complied with the spec. PUT is used for a 
different specification than POST and thus modifying PHP to treat them equally 
would not be a sane solution.

However, there are some simple steps to accomplishing what you want even though 
it would be in violation of the HTTP specification. Namely they would be:

1) You can detect whether or not PUT was the REQUEST method via 
$_SERVER['REQUEST_METHOD'] for example (depends on your SAPI).
2) You may then proceed to process the 'php://input' stream through something 
like file_get_contents('php://input'); - as an example.
3) You may then proceed to break up the multipart form data according to its 
defined boundaries in PHP user-space code -- according to the specification at 
http://tools.ietf.org/html/rfc2388
4) Finally you may chose to do with the file as you'd like (save, discard, 
otherwise).

However, it would make no sense at all to create a new superglobal in PHP 
called 
$_PUT since the HTTP PUT verb does not allow for multi-part/form data to begin 
with. So whoever is saying PHP is making

Bug #61744 [Nab]: preg_match crashes

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

 ID: 61744
 User updated by:bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:preg_match crashes
 Status: Not a bug
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Win 7 64-bit
 PHP Version:5.4.1RC2
 Block user comment: N
 Private report: N

 New Comment:

I think that this is not the fault of the stack.
In PHP 5.3 this problem does not occur.


Previous Comments:

[2012-04-16 17:36:37] paj...@php.net

Increase the stack, either using the http configuration or using the 
editbin.exe 
utility.

The stack is overridden by the executable running php, in case of mod_php it is 
apache's.


[2012-04-16 17:23:22] bugzilla33 at gmail dot com

No, I have original httpd.conf from package
and original php.ini-development -> php.ini


[2012-04-16 17:12:08] ras...@php.net

Are you using mod_security in your Apache?


[2012-04-16 16:53:59] bugzilla33 at gmail dot com

Tested also on Apache 2.4.2 + php_module (from www.apachelounge.com) + PHP 
5.4.0 VC9 Thread Safe

Test script still crashes.


[2012-04-16 16:37:16] bugzilla33 at gmail dot com

When use #^(A{1}B)+$# instead of #^(A{1,2}B)+$#
testcase returns 1 - no crash




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

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


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

Bug #61747 [Opn->Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 Updated by: ras...@php.net
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

The documentation is quite clear I think. In the first link you provided it 
says:

  If you have set a custom error handler function with set_error_handler() 
  then it will still get called, but this custom error handler can 
  (and should) call error_reporting() which will return 0 when the call 
  that triggered the error was preceded by an @.

I see no reason to change anything here. The current approach gives you all the 
control you need. If you have a custom error handler you can decide whether you 
want to ignore silenced calls or not. Any change to this would also be a major 
BC break.


Previous Comments:

[2012-04-16 17:57:52] chealer at gmail dot com

Description:

The at sign operator allows to "ignore" error messages, as explained in 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with 
set_error_handler() are nevertheless run when @ is used, which often causes 
such messages to show, as in the below example, where a custom error handler is 
used to customize the display of error messages.

As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show, 
this problem is not new. This behavior appears to be by design, and might be 
wanted in some cases.

Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs 
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when 
suppressing errors.
Make the documentation reflect the current state of things.

Alternatively, if the documentation of the @ operator isn't amended because 
custom error handlers are considered a corner case, then the 
set_error_handler() documentation should warn developers tempted to use custom 
error handlers that they are non-standard, not recommended/supported, and try 
to explain the pitfalls. In short, tell developers they should only use a 
custom error handler if they know what they're doing.

However, this alternative should be avoided since set_error_handler() is 
already used in several applications whose developers didn't receive the 
warning.

Test script:
---
My ERROR [$errno] $errstr\n";
echo "  Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;

case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;

case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;

default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}

// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale = 
$scale", E_USER_ERROR);
}

if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected", 
E_USER_WARNING);
return null;
}

$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0 
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}

return $temp;
}

$a = array(2, 3, "foo", 5.5, 43.3, 21.11);


/* Value at position $pos is not a number, using 0 (zero) */
scale_by_log($a, M_PI);
@scale_by_log($a, M_PI);

set_error_handler("myErrorHandler");
@scale_by_log($a, M_PI);

?>


Expected result:

Notice: Value at position 2 is not a number, using 0 (zero) in 
/var/www/atoperator.php on line 42

Call Stack:
0.0005 339192   1. {main}() /var/www/atoperator.php:0
0.0005 339836   2. scale_by_log(array (0 => 2, 1 => 3, 2 => 'foo', 3 => 
5.5, 4 => 43.3, 5 => 21.11), 3.1415926535898) /var/www/atoperator.php:55
0.0006 340648   3. trigger_error('Value at position 2 is not a number, 
using 0 (zero)', 1024) /var/www/atoperator.php:42

Actual result:
--
Notice: Value at position 2 is not a number, using 0 (zero) in 
/var/www/atoperator.php on line

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I'm sorry. This was fixed in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored.

If you have set a custom error handler function with set_error_handler() then 
it will still get called, but this custom error handler can (and should) call 
error_reporting() which will return 0 when the call that triggered the error 
was preceded by an @.


Note that this second sentence contradicts the first in some [edge] cases. At 
least, the second sentence should immediately follow the first, rather than 
having its own paragraph.


Previous Comments:

[2012-04-16 20:39:54] ras...@php.net

The documentation is quite clear I think. In the first link you provided it 
says:

  If you have set a custom error handler function with set_error_handler() 
  then it will still get called, but this custom error handler can 
  (and should) call error_reporting() which will return 0 when the call 
  that triggered the error was preceded by an @.

I see no reason to change anything here. The current approach gives you all the 
control you need. If you have a custom error handler you can decide whether you 
want to ignore silenced calls or not. Any change to this would also be a major 
BC break.


[2012-04-16 17:57:52] chealer at gmail dot com

Description:

The at sign operator allows to "ignore" error messages, as explained in 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with 
set_error_handler() are nevertheless run when @ is used, which often causes 
such messages to show, as in the below example, where a custom error handler is 
used to customize the display of error messages.

As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show, 
this problem is not new. This behavior appears to be by design, and might be 
wanted in some cases.

Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs 
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when 
suppressing errors.
Make the documentation reflect the current state of things.

Alternatively, if the documentation of the @ operator isn't amended because 
custom error handlers are considered a corner case, then the 
set_error_handler() documentation should warn developers tempted to use custom 
error handlers that they are non-standard, not recommended/supported, and try 
to explain the pitfalls. In short, tell developers they should only use a 
custom error handler if they know what they're doing.

However, this alternative should be avoided since set_error_handler() is 
already used in several applications whose developers didn't receive the 
warning.

Test script:
---
My ERROR [$errno] $errstr\n";
echo "  Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;

case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;

case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";
break;

default:
echo "Unknown error type: [$errno] $errstr\n";
break;
}
}

// function to test the error handling
function scale_by_log($vect, $scale)
{
if (!is_numeric($scale) || $scale <= 0) {
trigger_error("log(x) for x <= 0 is undefined, you used: scale = 
$scale", E_USER_ERROR);
}

if (!is_array($vect)) {
trigger_error("Incorrect input vector, array of values expected", 
E_USER_WARNING);
return null;
}

$temp = array();
foreach($vect as $pos => $value) {
if (!is_numeric($value)) {
trigger_error("Value at position $pos is not a number, using 0 
(zero)", E_USER_NOTICE);
$value = 0;
}
$temp[$pos] = log($scale) * $value;
}

return $temp;
}

$a = array(2, 3, "foo", 5.5, 43.3, 21.11);


/* Value

Bug #61091 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61091
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This was fixed by rasmus in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370

See also #61747.


Previous Comments:

[2012-02-19 23:05:25] chealer at gmail dot com

I understand that this problem only happens when using a custom error handler. 
But, if we assume the bug is in the documentation, the documentation should not 
assume the error handler used is the standard one. The problem I'm reporting 
here is not that the documentation doesn't explain how custom error handlers 
should be written, it's just the quoted statement, which is wrong in certain 
cases.

Alternatively, if the documentation of the @ operator isn't amended because 
custom error handlers are considered a corner case, then the 
set_error_handler() documentation should warn developers tempted to use custom 
error handlers that they are non-standard, not recommended/supported, and try 
to explain the pitfalls. In short, tell developers they should only use a 
custom error handler if they know what they're doing.

However, this alternative should be avoided since set_error_handler() is 
already used in several applications whose developers didn't receive the 
warning.


[2012-02-19 22:38:57] ras...@php.net

But it is unless you choose to override the default behaviour. And the 
documentation you hit when you do this override tells you how to check for @.


[2012-02-19 21:59:53] chealer at gmail dot com

I guess it does, but this report is not about error_reporting, it is about the 
@ error control operator.

According to the documentation of @, any error message that might be generated 
by the expression will be "ignored". Either the PHP interpreter is changed so 
that this becomes the case, or, if the current behavior is desired, the 
documentation is adapted to reflect the actual semantics.

To be perfectly clear, I am not asking to change the de facto semantics. I am 
only asking that whatever semantics is used by the implementation matches the 
documented semantics.


[2012-02-19 20:24:52] ras...@php.net

It says, "however you are still able to read the current value of 
error_reporting 
and act appropriately" followed by "Of particular note is that this value will 
be 
0 if the statement that caused the error was prepended by the @ error-control 
operator."

To me this says quite clearly that error_reporting will be 0 if the @ was used 
and that your custom error handler can read this value and "act appropriately."


[2012-02-19 19:49:22] chealer at gmail dot com

Rasmus, the part you quoted is about error_reporting() settings, it merely 
mentions the error control operator.

My question was, could you quote where "http://www.php.net/set_error_handler 
[...] explains that the user-defined error 
handler should check the error_reporting level in order to comply with the '@' 
if so desired"?




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

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


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

[PHP-BUG] Bug #61748 [NEW]: New PHPT test for PDO_sqlite

2012-04-16 Thread chris at kombine dot co dot uk

From: 
Operating system: linux (Xubuntu 11.10 64bit)
PHP version:  5.4.1RC2
Package:  Testing related
Bug Type: Bug
Bug description:New PHPT test for PDO_sqlite

Description:

This is my first (small) contribution to the QA testing effort. I was
advised to 
submit the test here as a bug to keep track of it. 

Default php.ini


Test script:
---
--TEST--
PDO_sqlite: Testing sqliteCreateFunction() produces warning when
un-callable function passed
--CREDITS--
Chris MacPherson ch...@kombine.co.uk
--SKIPIF--

--FILE--
sqliteCreateFunction('bar-alias', 'bar');

?>
--EXPECTF--
Warning: PDO::sqliteCreateFunction(): function 'bar' is not callable
in %s on line %d


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

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}

However, it would be rather inefficient if custom error handlers *should* (had 
to) do that, in general. If that was the case, PHP should simply not call 
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only 
in some cases.


Previous Comments:

[2012-04-16 20:59:18] chealer at gmail dot com

I'm sorry. This was fixed in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored.

If you have set a custom error handler function with set_error_handler() then 
it will still get called, but this custom error handler can (and should) call 
error_reporting() which will return 0 when the call that triggered the error 
was preceded by an @.


Note that this second sentence contradicts the first in some [edge] cases. At 
least, the second sentence should immediately follow the first, rather than 
having its own paragraph.


[2012-04-16 20:39:54] ras...@php.net

The documentation is quite clear I think. In the first link you provided it 
says:

  If you have set a custom error handler function with set_error_handler() 
  then it will still get called, but this custom error handler can 
  (and should) call error_reporting() which will return 0 when the call 
  that triggered the error was preceded by an @.

I see no reason to change anything here. The current approach gives you all the 
control you need. If you have a custom error handler you can decide whether you 
want to ignore silenced calls or not. Any change to this would also be a major 
BC break.


[2012-04-16 17:57:52] chealer at gmail dot com

Description:

The at sign operator allows to "ignore" error messages, as explained in 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with 
set_error_handler() are nevertheless run when @ is used, which often causes 
such messages to show, as in the below example, where a custom error handler is 
used to customize the display of error messages.

As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show, 
this problem is not new. This behavior appears to be by design, and might be 
wanted in some cases.

Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs 
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when 
suppressing errors.
Make the documentation reflect the current state of things.

Alternatively, if the documentation of the @ operator isn't amended because 
custom error handlers are considered a corner case, then the 
set_error_handler() documentation should warn developers tempted to use custom 
error handlers that they are non-standard, not recommended/supported, and try 
to explain the pitfalls. In short, tell developers they should only use a 
custom error handler if they know what they're doing.

However, this alternative should be avoided since set_error_handler() is 
already used in several applications whose developers didn't receive the 
warning.

Test script:
---
My ERROR [$errno] $errstr\n";
echo "  Fatal error on line $errline in file $errfile";
echo ", PHP " . PHP_VERSION . " (" . PHP_OS . ")\n";
echo "Aborting...\n";
exit(1);
break;

case E_USER_WARNING:
echo "My WARNING [$errno] $errstr\n";
break;

case E_USER_NOTICE:
echo "My NOTICE [$errno] $errstr\n";

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 Updated by: ras...@php.net
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.


Previous Comments:

[2012-04-16 21:23:27] chealer at gmail dot com

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}

However, it would be rather inefficient if custom error handlers *should* (had 
to) do that, in general. If that was the case, PHP should simply not call 
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only 
in some cases.


[2012-04-16 20:59:18] chealer at gmail dot com

I'm sorry. This was fixed in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored.

If you have set a custom error handler function with set_error_handler() then 
it will still get called, but this custom error handler can (and should) call 
error_reporting() which will return 0 when the call that triggered the error 
was preceded by an @.


Note that this second sentence contradicts the first in some [edge] cases. At 
least, the second sentence should immediately follow the first, rather than 
having its own paragraph.


[2012-04-16 20:39:54] ras...@php.net

The documentation is quite clear I think. In the first link you provided it 
says:

  If you have set a custom error handler function with set_error_handler() 
  then it will still get called, but this custom error handler can 
  (and should) call error_reporting() which will return 0 when the call 
  that triggered the error was preceded by an @.

I see no reason to change anything here. The current approach gives you all the 
control you need. If you have a custom error handler you can decide whether you 
want to ignore silenced calls or not. Any change to this would also be a major 
BC break.


[2012-04-16 17:57:52] chealer at gmail dot com

Description:

The at sign operator allows to "ignore" error messages, as explained in 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with 
set_error_handler() are nevertheless run when @ is used, which often causes 
such messages to show, as in the below example, where a custom error handler is 
used to customize the display of error messages.

As http://ca3.php.net/manual/en/language.operators.errorcontrol.php#98895 and 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php#85042 show, 
this problem is not new. This behavior appears to be by design, and might be 
wanted in some cases.

Therefore, please either:
Stop calling user-defined error handlers when suppressing errors. This needs 
serious consideration for backwards-compatibility.
Allow specifying whether user-defined error handlers should be called when 
suppressing errors.
Make the documentation reflect the current state of things.

Alternatively, if the documentation of the @ operator isn't amended because 
custom error handlers are considered a corner case, then the 
set_error_handler() documentation should warn developers tempted to use custom 
error handlers that they are non-standard, not recommended/supported, and try 
to explain the pitfalls. In short, tell developers they should only use a 
custom error handler if they know what they're doing.

However, this alternative should be avoided since set_error_handler() is 
already used in several applications whose developers didn't receive the 
warning.

Test script:
---
My ERROR [$errno] $err

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).


Previous Comments:

[2012-04-16 21:31:03] ras...@php.net

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.


[2012-04-16 21:23:27] chealer at gmail dot com

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}

However, it would be rather inefficient if custom error handlers *should* (had 
to) do that, in general. If that was the case, PHP should simply not call 
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only 
in some cases.


[2012-04-16 20:59:18] chealer at gmail dot com

I'm sorry. This was fixed in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored.

If you have set a custom error handler function with set_error_handler() then 
it will still get called, but this custom error handler can (and should) call 
error_reporting() which will return 0 when the call that triggered the error 
was preceded by an @.


Note that this second sentence contradicts the first in some [edge] cases. At 
least, the second sentence should immediately follow the first, rather than 
having its own paragraph.


[2012-04-16 20:39:54] ras...@php.net

The documentation is quite clear I think. In the first link you provided it 
says:

  If you have set a custom error handler function with set_error_handler() 
  then it will still get called, but this custom error handler can 
  (and should) call error_reporting() which will return 0 when the call 
  that triggered the error was preceded by an @.

I see no reason to change anything here. The current approach gives you all the 
control you need. If you have a custom error handler you can decide whether you 
want to ignore silenced calls or not. Any change to this would also be a major 
BC break.


[2012-04-16 17:57:52] chealer at gmail dot com

Description:

The at sign operator allows to "ignore" error messages, as explained in 
http://ca3.php.net/manual/en/language.operators.errorcontrol.php

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored. 

However, as reported in #61091, user-defined error handlers registered with 
set_error_handler() are nevertheless run when @ is used, which often causes 
such messages to show, as in the below example, where a custom error handler is 
used to customize the display

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 Updated by: ras...@php.net
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.


Previous Comments:

[2012-04-16 21:50:00] chealer at gmail dot com

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).


[2012-04-16 21:31:03] ras...@php.net

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.


[2012-04-16 21:23:27] chealer at gmail dot com

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}

However, it would be rather inefficient if custom error handlers *should* (had 
to) do that, in general. If that was the case, PHP should simply not call 
user-defined error handlers when @ was used.
I think user-defined error handlers *should* do something like that, but only 
in some cases.


[2012-04-16 20:59:18] chealer at gmail dot com

I'm sorry. This was fixed in 
http://svn.php.net/viewvc/phpdoc/en/trunk/language/operators.xml?r1=322134&r2=323370
We now have:

When prepended to an expression in PHP, any error messages that might be 
generated by that expression will be ignored.

If you have set a custom error handler function with set_error_handler() then 
it will still get called, but this custom error handler can (and should) call 
error_reporting() which will return 0 when the call that triggered the error 
was preceded by an @.


Note that this second sentence contradicts the first in some [edge] cases. At 
least, the second sentence should immediately follow the first, rather than 
having its own paragraph.


[2012-04-

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

You write:
If you choose to treat @-preceded errors like any other error, that's fine.

Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a 
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors 
like any other error call error_reporting()?

You write:
By default PHP ignores errors from calls preceded by @, but since you are 
writing your own you should have the power to override any and all such 
defaults.

I'm not sure I would say that custom error handlers *should* have the power to 
override error suppression, but I certainly understand that it can be useful. 
In any case, offering that flexibility doesn't have to make it more complicated 
to write a simple custom handler. set_error_handler() could simply have an 
argument to control whether the callback is called even on normally suppressed 
errors.


Previous Comments:

[2012-04-16 22:34:14] ras...@php.net

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.


[2012-04-16 21:50:00] chealer at gmail dot com

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).


[2012-04-16 21:31:03] ras...@php.net

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.


[2012-04-16 21:23:27] chealer at gmail dot com

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
[...]
}

However, it would be rather inefficient if custom error handlers *should* (had 
to) do that, in general. If that was the case, PHP should simply not call

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 Updated by: ras...@php.net
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Right, it says "should" not "must". If you choose to not treat @ differently, 
then you obviously don't need to call error_reporting() from your handler.


Previous Comments:

[2012-04-17 00:36:29] chealer at gmail dot com

You write:
If you choose to treat @-preceded errors like any other error, that's fine.

Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a 
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors 
like any other error call error_reporting()?

You write:
By default PHP ignores errors from calls preceded by @, but since you are 
writing your own you should have the power to override any and all such 
defaults.

I'm not sure I would say that custom error handlers *should* have the power to 
override error suppression, but I certainly understand that it can be useful. 
In any case, offering that flexibility doesn't have to make it more complicated 
to write a simple custom handler. set_error_handler() could simply have an 
argument to control whether the callback is called even on normally suppressed 
errors.


[2012-04-16 22:34:14] ras...@php.net

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.


[2012-04-16 21:50:00] chealer at gmail dot com

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).


[2012-04-16 21:31:03] ras...@php.net

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.


[2012-04-16 21:23:27] chealer at gmail dot com

This is a duplicate of #52338.

Note that I partly disagree with the fix. Custom error handlers *can* check 
error_reporting(), as illustrated in the example from 
http://ca3.php.net/manual/en/function.set-error-handler.php

function myErrorHandler($errno, $errstr, $errfile, $errline)
{
if (!(error_reporting

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Right. So, the documentation is saying custom error handlers should treat 
suppressed errors differently. You are saying it is fine not to do that.
I think your version is right.


Previous Comments:

[2012-04-17 00:59:34] ras...@php.net

Right, it says "should" not "must". If you choose to not treat @ differently, 
then you obviously don't need to call error_reporting() from your handler.


[2012-04-17 00:36:29] chealer at gmail dot com

You write:
If you choose to treat @-preceded errors like any other error, that's fine.

Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a 
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors 
like any other error call error_reporting()?

You write:
By default PHP ignores errors from calls preceded by @, but since you are 
writing your own you should have the power to override any and all such 
defaults.

I'm not sure I would say that custom error handlers *should* have the power to 
override error suppression, but I certainly understand that it can be useful. 
In any case, offering that flexibility doesn't have to make it more complicated 
to write a simple custom handler. set_error_handler() could simply have an 
argument to control whether the callback is called even on normally suppressed 
errors.


[2012-04-16 22:34:14] ras...@php.net

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.


[2012-04-16 21:50:00] chealer at gmail dot com

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).


[2012-04-16 21:31:03] ras...@php.net

There is nothing inefficient about calling error_reporting(). It is a trivially 
small and fast internal function. And like I said, changing anything here would 
be a major BC break. There is nothing wrong with the current implementation.




The remainder of the comments for this report are too long

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 Updated by: ras...@php.net
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

No, I think a custom error handler should make good use of the silence 
operator. 
There are all kinds of interesting things you can do with it. But yes, if you 
want to ignore it entirely, that is fine too.


Previous Comments:

[2012-04-17 01:40:34] chealer at gmail dot com

Right. So, the documentation is saying custom error handlers should treat 
suppressed errors differently. You are saying it is fine not to do that.
I think your version is right.


[2012-04-17 00:59:34] ras...@php.net

Right, it says "should" not "must". If you choose to not treat @ differently, 
then you obviously don't need to call error_reporting() from your handler.


[2012-04-17 00:36:29] chealer at gmail dot com

You write:
If you choose to treat @-preceded errors like any other error, that's fine.

Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a 
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors 
like any other error call error_reporting()?

You write:
By default PHP ignores errors from calls preceded by @, but since you are 
writing your own you should have the power to override any and all such 
defaults.

I'm not sure I would say that custom error handlers *should* have the power to 
override error suppression, but I certainly understand that it can be useful. 
In any case, offering that flexibility doesn't have to make it more complicated 
to write a simple custom handler. set_error_handler() could simply have an 
argument to control whether the callback is called even on normally suppressed 
errors.


[2012-04-16 22:34:14] ras...@php.net

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.


[2012-04-16 21:50:00] chealer at gmail dot com

I meant it would be inefficient to ask PHP programmers to include

if (!(error_reporting() & $errno)) {
   // This error code is not included in error_reporting
   return;
}

in all custom error handlers they write, if the problem could be addressed once 
and for all by the PHP interpreter.

If that is your stance though, this requirement should be documented in 
http://ca3.php.net/manual/en/function.set-error-handler.php
And if you really think that custom error handlers should ignore suppressed 
errors, then not calling custom error handlers would be more of a bugfix (for 
those handlers that fail to do it) than a BC break. Certainly, that wouldn't be 
a "major BC break", although it may be disruptive enough to warrant waiting for 
a major release to do such a behavior change.

I'm not saying there's something *wrong* (in the sense of buggy) with the 
current implementation, as long as how it works is documented (which wasn't the 
case until recently), and the requirement to check for suppressed errors is 
documented in set_error_handler()'s documentation (which is still not the case).




The remainder of the comments for this report are too long. To view
the rest of the comme

Bug #61747 [Nab]: User-defined error handler run despite at sign (@) error control operator

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

 ID: 61747
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:User-defined error handler run despite at sign (@)
 error control operator
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

No what? It's not fine not to treat suppressed errors differently?


Previous Comments:

[2012-04-17 02:00:40] ras...@php.net

No, I think a custom error handler should make good use of the silence 
operator. 
There are all kinds of interesting things you can do with it. But yes, if you 
want to ignore it entirely, that is fine too.


[2012-04-17 01:40:34] chealer at gmail dot com

Right. So, the documentation is saying custom error handlers should treat 
suppressed errors differently. You are saying it is fine not to do that.
I think your version is right.


[2012-04-17 00:59:34] ras...@php.net

Right, it says "should" not "must". If you choose to not treat @ differently, 
then you obviously don't need to call error_reporting() from your handler.


[2012-04-17 00:36:29] chealer at gmail dot com

You write:
If you choose to treat @-preceded errors like any other error, that's fine.

Yet http://ca3.php.net/manual/en/language.operators.errorcontrol.php says a 
custom error handler should call error_reporting().
So why should a custom error handler which chooses to treat @-preceded errors 
like any other error call error_reporting()?

You write:
By default PHP ignores errors from calls preceded by @, but since you are 
writing your own you should have the power to override any and all such 
defaults.

I'm not sure I would say that custom error handlers *should* have the power to 
override error suppression, but I certainly understand that it can be useful. 
In any case, offering that flexibility doesn't have to make it more complicated 
to write a simple custom handler. set_error_handler() could simply have an 
argument to control whether the callback is called even on normally suppressed 
errors.


[2012-04-16 22:34:14] ras...@php.net

I didn't say that I think custom error handlers should ignore suppressed 
errors. 
I said that the authors of the custom error handlers should decide what to do 
with them so they should called error_reporting() and take an appropriate 
action. I have seen systems that use the @ to classify something that generates 
an E_WARNING as non-critical for example, where an E_WARNING without the @ 
causes someone to get paged.

And it is documented on the set_error_handler() page. It says:

  error_reporting() settings will have no effect and your error handler 
  will be called regardless - however you are still able to read the 
  current value of error_reporting and act appropriately. Of particular
  note is that this value will be 0 if the statement that caused the
  error was prepended by the @ error-control operator.

The point of a custom error handler is to override the default PHP error 
handling behaviour. By default PHP ignores errors from calls preceded by @, but 
since you are writing your own you should have the power to override any and 
all 
such defaults. If you choose to treat @-preceded errors like any other error, 
that's fine.

This really isn't going to change.




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

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


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

Req #60408 [Asn->Csd]: Array/String element access on instantiation (same like class member in 5.4RC)

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

 ID: 60408
 Updated by: larue...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:Array/String element access on instantiation (same
 like class member in 5.4RC)
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.4.0RC2
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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

committed into trunk.


Previous Comments:

[2011-12-27 09:41:48] larue...@php.net

dmitry, thanks very much for pointing that out, I will try to fix these issues. 
:)


[2011-12-27 09:36:25] dmi...@php.net

I would say the patch is wrong. It misses the possibility of container_ptr 
separation in zend_fetch_dimension_address_read(). It also won't work with 
ZEND_FETCH_DIM_FUNC_ARG.


[2011-11-30 09:46:38] larue...@php.net

The following patch has been added/updated:

Patch Name: const_dereference_002.phpt
Revision:   1322646398
URL:
https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_002.phpt&revision=1322646398


[2011-11-30 09:46:27] larue...@php.net

The following patch has been added/updated:

Patch Name: const_dereference_003.phpt
Revision:   1322646387
URL:
https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_003.phpt&revision=1322646387


[2011-11-30 09:46:09] larue...@php.net

The following patch has been added/updated:

Patch Name: const_dereference_001.phpt
Revision:   1322646369
URL:
https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_001.phpt&revision=1322646369




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

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


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

[PHP-BUG] Bug #61750 [NEW]: php-fpm can not load mbstring module

2012-04-16 Thread yolongyi at gmail dot com

From: 
Operating system: Linux
PHP version:  5.3.10
Package:  FPM related
Bug Type: Bug
Bug description:php-fpm can not load mbstring module

Description:

>From the command line, I can use the functions of mbstring like,

$ret = mb_detect_encoding("this is a test");
// do something with $ret

It does well. I can get the right result for $ret.


but if I open the same file from the browser via web server ( NginX +
php-fpm ),
it errors 'mb_detect_encoding' function does not exists.


I use the same php and php.ini in both command line and php-fpm.
( checked with phpinfo() )
and compiled php with '--enable-mbstring'
( also check with phpinfo() )



I think there must be some bug in php-fpm when it executes scripts.

Test script:
---


Expected result:

result: 1

Actual result:
--
result:1  <--- in command line
result:   <--- in browser

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

Bug #61750 [Opn->Fbk]: php-fpm can not load mbstring module