Bug #18556 [Csd]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Updated by: s...@php.net Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:stas Block user comment: N Private report: N New Comment: You should be using 5.5 (or master) branch of PHP. It is not fixed in 5.4 due to necessities of binary APIs change which is not possible in stable version. Trunk does not announce itself as 5.4 but as 5.5, so there must be some mistake. However if you feel very adventurous, you can take 5.5 commit (it's marked with the bug #) and cherry-pick it into your 5.4 branch. Previous Comments: [2012-09-08 14:54:04] richlv at nakts dot net hmm, i just tested trunk snapshot php-trunk-201209081330 which announces itself as 5.4.8-dev trying to use turkish locale still fails with : Fatal error: Class 'CInput' not found (there's uppercase I in the name) what am i doing wrong ? [2012-09-08 14:25:15] richlv at nakts dot net which version is expected to have the fix ? looking at snapshots, is it trunk only (thus php 5.5 or whichever will be the next version) ? interesting bit - this bug was fixed just 9 days short of it's 10th birthday ;) (submitted 2002-07-25, fixed 2012-07-16) [2012-07-16 14:21:36] me at ollieread dot com I don't know how helpful this will be, but I've recently had an issue with the Turkish locale where I work. I tried lots of different methods, but the main issue seems to be with LC_CTYPE, as although class/method declarations include I, it's added to the stack as i. I've wrote a couple of fixes that hopefully approach all cases, be warned, they are however a bit hacky. http://codeosaur.us/2012/07/16/php-and-the-tr_tr-utf8-locale/ You can simple explicitly set LC_CTYPE to your native language(eg en_US.utf8), but if you absolutely must have tr_TR.utf8 there, then you can use the magic of __autoload(), __call() and class_alias to handle it for you. Hope this helps. [2012-07-14 22:59:37] s...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed in master. [2012-07-04 08:52:28] maar...@php.net @ stormbyte, I just made 2 separate more explicit tests, one for tr_TR.iso8859-9 and one for tr_TR.UTF-8 and they do have the same outcome: tr_TR.iso8859-9 - http://3v4l.org/o5YCk tr_TR.UTF-8 - http://3v4l.org/F2gEb 3v4l.org uses a 'vanilla' PHP setup, be free to play with phpinfo() and the likes to see for yourself. 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=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
Req #63052 [Opn->Asn]: ext/date/lib/timezonedb.h is not updated long time
Edit report at https://bugs.php.net/bug.php?id=63052&edit=1 ID: 63052 Updated by: ahar...@php.net Reported by:litos at mail dot ru Summary:ext/date/lib/timezonedb.h is not updated long time -Status: Open +Status: Assigned Type: Feature/Change Request Package:Date/time related Operating System: all PHP Version:master-Git-2012-09-10 (Git) -Assigned To: +Assigned To:derick Block user comment: N Private report: N New Comment: Assigning to Derick, since he generally handles the time zone updates. Previous Comments: [2012-09-10 06:08:35] litos at mail dot ru Description: http://git.php.net/?p=php- src.git;a=history;f=ext/date/lib/timezonedb.h;h=221181191eaef173b9ae02cef28100d0a3 1b2581;hb=HEAD timezonedb.h have version number 2012.3 (2012c) but actual verion now is 2012.5 (2012e) Please update regularly this file -- Edit this bug report at https://bugs.php.net/bug.php?id=63052&edit=1
[PHP-BUG] Req #63052 [NEW]: ext/date/lib/timezonedb.h is not updated long time
From: litos at mail dot ru Operating system: all PHP version: master-Git-2012-09-10 (Git) Package: Date/time related Bug Type: Feature/Change Request Bug description:ext/date/lib/timezonedb.h is not updated long time Description: http://git.php.net/?p=php- src.git;a=history;f=ext/date/lib/timezonedb.h;h=221181191eaef173b9ae02cef28100d0a3 1b2581;hb=HEAD timezonedb.h have version number 2012.3 (2012c) but actual verion now is 2012.5 (2012e) Please update regularly this file -- Edit bug report at https://bugs.php.net/bug.php?id=63052&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63052&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63052&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63052&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63052&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63052&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63052&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63052&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63052&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63052&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63052&r=support Expected behavior: https://bugs.php.net/fix.php?id=63052&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63052&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63052&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63052&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63052&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63052&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63052&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63052&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63052&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63052&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63052&r=mysqlcfg
Bug #52559 [Asn->Csd]: Calling undefined method on FilterIterator subclasses causes segfault
Edit report at https://bugs.php.net/bug.php?id=52559&edit=1 ID: 52559 Updated by: ahar...@php.net Reported by:tobias382 at gmail dot com Summary:Calling undefined method on FilterIterator subclasses causes segfault -Status: Assigned +Status: Closed Type: Bug Package:SPL related Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2010-08-06 (snap) -Assigned To:colder +Assigned To:laruence Block user comment: N Private report: N New Comment: Fixed in cc30524c89fa2255944dc3c70f8d41a6c23faa2a, for those playing at home. Previous Comments: [2012-09-10 03:55:47] reeze dot xia at gmail dot com THis bug has been fixed already, could be closed :) see: http://3v4l.org/eavLE [2010-08-07 03:42:22] tobias382 at gmail dot com Description: The attached test script causes a segmentation fault in PHP 5.3.3 and the current PHP 5.3 snapshot, presumably because count() is not a defined method in FooIterator or any of its ancestor classes. The configure line used to compile the snapshot: Configure Command => './configure' '--prefix=/home/matt/Software/php5.3- 201008070030/build/php_build' '--without-pear' '--without-sqlite3' '--without- pdo-sqlite' '--without-sqlite' '--enable-debug' Test script: --- count(); Expected result: PHP Fatal error: Call to undefined method FooIterator::count() in test.php on line 8 Actual result: -- 1Segmentation fault gdb backtrace: #0 0x02926cd0 in ?? () #1 0x00573929 in spl_dual_it_free (intern=0x2a089f0) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1461 #2 0x00574ebd in spl_dual_it_dtor (_object=0x2a089f0, handle=1) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1942 #3 0x006ebbea in zend_objects_store_del_ref_by_handle_ex (handle=1, handlers=0xcace80) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:206 #4 0x006eba5f in zend_objects_store_del_ref (zobject=0x2a20e30) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:172 #5 0x006bbca2 in _zval_dtor_func (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c:52 #6 0x006abbba in _zval_dtor (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3-201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.h:35 #7 0x006acb48 in _zval_ptr_dtor (zval_ptr=0x2a24158, __zend_filename=0xa50290 "/home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c", __zend_lineno=178) at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:443 #8 0x006bc01f in _zval_ptr_dtor_wrapper (zval_ptr=0x2a24158) at /home/matt/Software/php5.3-201008070030/Zend/zend_variables.c:178 #9 0x006ce705 in zend_hash_apply_deleter (ht=0xcc4588, p=0x2a24140) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:611 #10 0x006ced8e in zend_hash_reverse_apply (ht=0xcc4588, apply_func=0x6ac3f5 ) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:760 #11 0x006ac487 in shutdown_destructors () at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:226 #12 0x006bd8db in zend_call_destructors () at /home/matt/Software/php5.3-201008070030/Zend/zend.c:874 #13 0x00647cec in php_request_shutdown (dummy=0x0) at /home/matt/Software/php5.3-201008070030/main/main.c:1587 #14 0x007a27db in main (argc=2, argv=0x7fffd4f78e68) at /home/matt/Software/php5.3-201008070030/sapi/cli/php_cli.c:1373 -- Edit this bug report at https://bugs.php.net/bug.php?id=52559&edit=1
Bug #52559 [Com]: Calling undefined method on FilterIterator subclasses causes segfault
Edit report at https://bugs.php.net/bug.php?id=52559&edit=1 ID: 52559 Comment by: reeze dot xia at gmail dot com Reported by:tobias382 at gmail dot com Summary:Calling undefined method on FilterIterator subclasses causes segfault Status: Assigned Type: Bug Package:SPL related Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2010-08-06 (snap) Assigned To:colder Block user comment: N Private report: N New Comment: THis bug has been fixed already, could be closed :) see: http://3v4l.org/eavLE Previous Comments: [2010-08-07 03:42:22] tobias382 at gmail dot com Description: The attached test script causes a segmentation fault in PHP 5.3.3 and the current PHP 5.3 snapshot, presumably because count() is not a defined method in FooIterator or any of its ancestor classes. The configure line used to compile the snapshot: Configure Command => './configure' '--prefix=/home/matt/Software/php5.3- 201008070030/build/php_build' '--without-pear' '--without-sqlite3' '--without- pdo-sqlite' '--without-sqlite' '--enable-debug' Test script: --- count(); Expected result: PHP Fatal error: Call to undefined method FooIterator::count() in test.php on line 8 Actual result: -- 1Segmentation fault gdb backtrace: #0 0x02926cd0 in ?? () #1 0x00573929 in spl_dual_it_free (intern=0x2a089f0) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1461 #2 0x00574ebd in spl_dual_it_dtor (_object=0x2a089f0, handle=1) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1942 #3 0x006ebbea in zend_objects_store_del_ref_by_handle_ex (handle=1, handlers=0xcace80) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:206 #4 0x006eba5f in zend_objects_store_del_ref (zobject=0x2a20e30) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:172 #5 0x006bbca2 in _zval_dtor_func (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c:52 #6 0x006abbba in _zval_dtor (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3-201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.h:35 #7 0x006acb48 in _zval_ptr_dtor (zval_ptr=0x2a24158, __zend_filename=0xa50290 "/home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c", __zend_lineno=178) at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:443 #8 0x006bc01f in _zval_ptr_dtor_wrapper (zval_ptr=0x2a24158) at /home/matt/Software/php5.3-201008070030/Zend/zend_variables.c:178 #9 0x006ce705 in zend_hash_apply_deleter (ht=0xcc4588, p=0x2a24140) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:611 #10 0x006ced8e in zend_hash_reverse_apply (ht=0xcc4588, apply_func=0x6ac3f5 ) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:760 #11 0x006ac487 in shutdown_destructors () at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:226 #12 0x006bd8db in zend_call_destructors () at /home/matt/Software/php5.3-201008070030/Zend/zend.c:874 #13 0x00647cec in php_request_shutdown (dummy=0x0) at /home/matt/Software/php5.3-201008070030/main/main.c:1587 #14 0x007a27db in main (argc=2, argv=0x7fffd4f78e68) at /home/matt/Software/php5.3-201008070030/sapi/cli/php_cli.c:1373 -- Edit this bug report at https://bugs.php.net/bug.php?id=52559&edit=1
Req #24173 [Opn->Dup]: ability and get dup headers
Edit report at https://bugs.php.net/bug.php?id=24173&edit=1 ID: 24173 Updated by: ahar...@php.net Reported by:Xuefer at 21cn dot com Summary:ability and get dup headers -Status: Open +Status: Duplicate Type: Feature/Change Request Package:Apache related Operating System: all PHP Version:4.3.2 Block user comment: N Private report: N New Comment: Agreed. Thanks for pointing it out! Previous Comments: [2012-09-09 12:10:59] space at wechall dot net This can be closed as duplicate of Bug #44744. [2003-06-13 08:16:55] Xuefer at 21cn dot com Description: current apache_response_headers() is not able to return multi headers, e.g.: 2 Set-Cookie, only 1 returned, because it return array, which store only unique key so i suggest that, add apache_response_headers(true) to return array like this: array( 0=> "Content-Type: ..", 1=> "Set-Cookie: ...", 2=> "Set-Cookie: ...", 3=> "Set-Cookie: ...", ); -- Edit this bug report at https://bugs.php.net/bug.php?id=24173&edit=1
Bug #40837 [Nab]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1 ID: 40837 Updated by: ahar...@php.net Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: For the record, there's no way this can be implemented as it stands: for backward compatibility reasons, instance methods can be called statically, so the name has to be distinct to disambiguate between static and instance methods. The call type is not enough. Previous Comments: [2012-09-07 22:33:55] accounts dot php at nickawilliams dot com I also support this proposal. On numerous occasions throughout my career writing PHP I have found a need for this. While there are workarounds that work, they are all fairly verbose, convoluted, and/or difficult to follow. Please consider reopening this! [2012-08-04 00:46:35] billco at fnarg dot com Same here! This is a very useful pattern in other languages, where the same method name can be used in both static and non-static contexts. For example, a search() method in static context could create a new result object, while the non-static form would search within an existing result set. While it is possible to mimic this sort of behaviour by first creating a "blank" object, it leads to dual-purpose methods (a big "if" statement), resulting in messy, unmaintainable code. Why arbitrarily force developers to violate good OOP practices ? [2012-06-28 08:15:27] info at renemaas dot de Yeah this would be really helpful. I hope anybody of the PHP team will implement this kind of "stupid" feature. If not them please provide a "cool" solution for using static and non-static functions. [2011-12-21 18:26:14] mac at macnewbold dot com I agree with martijntje and nick.telford - the static function and normal function of the same name shouldn't have any conflict, and it would be extremely helpful to be able to define the same function for use both statically and non-statically. In the meantime, I'm going to try using __call() and __callStatic() to pretend like this feature actually exists. [2011-11-26 22:17:42] martijntje at martijnotto dot nl I have no idea why this bug is closed as 'bogus'. Just because the documentation states it is a certain way does not mean that it is right. I, for one, believe that it should be possible to create both a static and a member function with the same name. There would never be any confusion as to which function should be called due to the difference of using the :: or -> operator. 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=40837 -- Edit this bug report at https://bugs.php.net/bug.php?id=40837&edit=1
Bug #52003 [Asn]: Incorrect PDOStatement::execute() signature
Edit report at https://bugs.php.net/bug.php?id=52003&edit=1
ID: 52003
Updated by: larue...@php.net
Reported by:v1d4l0k4 at gmail dot com
Summary:Incorrect PDOStatement::execute() signature
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Irrelevant
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
maybe change to doc problem, there maybe already some user defined their
extended
class with the *wrong* signature.
Previous Comments:
[2012-09-09 14:37:41] reeze dot xia at gmail dot com
This seems been forgotten by pierrick.
[2012-01-30 05:52:51] larry at ldrutledge dot com
The situation appears to be unchanged in 5.3.9. The manual still shows a type
hint of array but a method in an extended class still triggers a warning unless
the type hint is omitted.
[2010-10-19 07:07:17] ka...@php.net
Pierrick, why don't you commit that patch the src? And add a changelog entry if
reasonable for PDOStatement::execute() :)
[2010-06-06 06:13:42] pierr...@php.net
The following patch has been added/updated:
Patch Name: ZEND_ARG_ARRAY_INFO
Revision: 1275797622
URL:
http://bugs.php.net/patch-display.php?bug=52003&patch=ZEND_ARG_ARRAY_INFO&revision=1275797622
[2010-06-05 22:53:10] v1d4l0k4 at gmail dot com
Description:
Manual says PDOStatement::execute() signature is:
bool PDOStatement::execute ([ array $input_parameters = array() ] )
But in fact it is:
bool PDOStatement::execute ([ $input_parameters = null ] )
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('DBStatement'));
Expected result:
No errors
Actual result:
--
Strict Standards: Declaration of DBStatement::execute() should be compatible
with that of PDOStatement::execute() in /media/ext/Web/htdocs/test/bug.php on
line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=52003&edit=1
Bug #62962 [Opn->Csd]: Test failed ext/zlib/tests/bug_52944.phpt
Edit report at https://bugs.php.net/bug.php?id=62962&edit=1 ID: 62962 Updated by: a...@php.net Reported by:reeze dot xia at gmail dot com Summary:Test failed ext/zlib/tests/bug_52944.phpt -Status: Open +Status: Closed Type: Bug Package:Zlib related Operating System: Mac OSX 10.8 PHP Version:5.4Git-2012-08-29 (Git) -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. commited Previous Comments: [2012-08-29 09:01:18] reeze dot xia at gmail dot com Description: ext/zlib/tests/bug_52944.phpt test failed Expected result: Pass Actual result: -- failed. â php-src-5.4 git:(PHP-5.4) â cat ext/zlib/tests/bug_52944.diff 001+ string(1) "%" 002+ string(1) "C" 001- string(0) "" 002- string(0) "" -- Edit this bug report at https://bugs.php.net/bug.php?id=62962&edit=1
Bug #63047 [Csd->Nab]: Easter date is wrong
Edit report at https://bugs.php.net/bug.php?id=63047&edit=1 ID: 63047 Updated by: ras...@php.net Reported by:aschenaz at gmail dot com Summary:Easter date is wrong -Status: Closed +Status: Not a bug Type: Bug Package:Calendar related Operating System: Linux PHP Version:5.4.6 Block user comment: N Private report: N Previous Comments: [2012-09-09 11:55:18] aschenaz at gmail dot com It was my fault. With the last upgrade of php, php.ini (with a timezone set) was been overwritten and now it had no timezone. I beg your pardon. [2012-09-09 09:46:59] aschenaz at gmail dot com Description: Asking for Easter date function, it will result Apr-07-2012, but it should be Apr-08-2012! That is important for liturgic year calculations. Test script: --- Expected result: Apr-08-2012 Actual result: -- Apr-07-2012 -- Edit this bug report at https://bugs.php.net/bug.php?id=63047&edit=1
Bug #52003 [Com]: Incorrect PDOStatement::execute() signature
Edit report at https://bugs.php.net/bug.php?id=52003&edit=1
ID: 52003
Comment by: reeze dot xia at gmail dot com
Reported by:v1d4l0k4 at gmail dot com
Summary:Incorrect PDOStatement::execute() signature
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Irrelevant
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
This seems been forgotten by pierrick.
Previous Comments:
[2012-01-30 05:52:51] larry at ldrutledge dot com
The situation appears to be unchanged in 5.3.9. The manual still shows a type
hint of array but a method in an extended class still triggers a warning unless
the type hint is omitted.
[2010-10-19 07:07:17] ka...@php.net
Pierrick, why don't you commit that patch the src? And add a changelog entry if
reasonable for PDOStatement::execute() :)
[2010-06-06 06:13:42] pierr...@php.net
The following patch has been added/updated:
Patch Name: ZEND_ARG_ARRAY_INFO
Revision: 1275797622
URL:
http://bugs.php.net/patch-display.php?bug=52003&patch=ZEND_ARG_ARRAY_INFO&revision=1275797622
[2010-06-05 22:53:10] v1d4l0k4 at gmail dot com
Description:
Manual says PDOStatement::execute() signature is:
bool PDOStatement::execute ([ array $input_parameters = array() ] )
But in fact it is:
bool PDOStatement::execute ([ $input_parameters = null ] )
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('DBStatement'));
Expected result:
No errors
Actual result:
--
Strict Standards: Declaration of DBStatement::execute() should be compatible
with that of PDOStatement::execute() in /media/ext/Web/htdocs/test/bug.php on
line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=52003&edit=1
[PHP-BUG] Req #63049 [NEW]: iterator_to_array for recursive iterators
From: franssen dot roland at gmail dot com Operating system: Ubuntu PHP version: 5.4.6 Package: SPL related Bug Type: Feature/Change Request Bug description:iterator_to_array for recursive iterators Description: It would be nice to have a recursive_iterator_to_array function to transform a \RecursiveIterator to a full recursive array... -- Edit bug report at https://bugs.php.net/bug.php?id=63049&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63049&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63049&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63049&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63049&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63049&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63049&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63049&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63049&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63049&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63049&r=support Expected behavior: https://bugs.php.net/fix.php?id=63049&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63049&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63049&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63049&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63049&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63049&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63049&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63049&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63049&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63049&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63049&r=mysqlcfg
Req #44744 [Com]: apache_response_headers() does not include duplicate headers
Edit report at https://bugs.php.net/bug.php?id=44744&edit=1
ID: 44744
Comment by: space at wechall dot net
Reported by:chsc at peytz dot dk
Summary:apache_response_headers() does not include duplicate
headers
Status: Open
Type: Feature/Change Request
Package:Apache2 related
Operating System: Linux
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Also in PHP 5.3.10â¦
i will test it on PHP 5.4 ASAPâ¦
Bug #25173 can be closed as duplicate of thisâ¦
Previous Comments:
[2008-04-16 16:25:43] chsc at peytz dot dk
Description:
When multiple response headers with the same name are set using header(...,
false), only the last value is returned by apache_response_headers().
apache_response_headers() returns an associative array, so it cannot have
multiple entries for the same header name. However, according to section 4.2 of
RFC 2616, multiple headers with the same name may be combined into one
comma-separated header.
It MUST be possible to combine the multiple header fields into
one "field-name: field-value" pair, without changing the semantics
of the message, by appending each subsequent field-value to the
first, each separated by a comma.
I suggest that apache_response_headers() does this, i.e. combines multiple
headers with comma.
Reproduce code:
---
header('Foo: 1');
header('Foo: 2', false);
header('Foo: 3', false);
var_dump(apache_response_headers());
Expected result:
array(2) {
["X-Powered-By"]=>
string(9) "PHP/5.2.5"
["Foo"]=>
string(1) "1,2,3"
}
Actual result:
--
array(2) {
["X-Powered-By"]=>
string(9) "PHP/5.2.5"
["Foo"]=>
string(1) "3"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=44744&edit=1
Req #24173 [Com]: ability and get dup headers
Edit report at https://bugs.php.net/bug.php?id=24173&edit=1 ID: 24173 Comment by: space at wechall dot net Reported by:Xuefer at 21cn dot com Summary:ability and get dup headers Status: Open Type: Feature/Change Request Package:Apache related Operating System: all PHP Version:4.3.2 Block user comment: N Private report: N New Comment: This can be closed as duplicate of Bug #44744. Previous Comments: [2003-06-13 08:16:55] Xuefer at 21cn dot com Description: current apache_response_headers() is not able to return multi headers, e.g.: 2 Set-Cookie, only 1 returned, because it return array, which store only unique key so i suggest that, add apache_response_headers(true) to return array like this: array( 0=> "Content-Type: ..", 1=> "Set-Cookie: ...", 2=> "Set-Cookie: ...", 3=> "Set-Cookie: ...", ); -- Edit this bug report at https://bugs.php.net/bug.php?id=24173&edit=1
Bug #63047 [Opn->Csd]: Easter date is wrong
Edit report at https://bugs.php.net/bug.php?id=63047&edit=1 ID: 63047 User updated by:aschenaz at gmail dot com Reported by:aschenaz at gmail dot com Summary:Easter date is wrong -Status: Open +Status: Closed Type: Bug Package:Calendar related Operating System: Linux PHP Version:5.4.6 Block user comment: N Private report: N New Comment: It was my fault. With the last upgrade of php, php.ini (with a timezone set) was been overwritten and now it had no timezone. I beg your pardon. Previous Comments: [2012-09-09 09:46:59] aschenaz at gmail dot com Description: Asking for Easter date function, it will result Apr-07-2012, but it should be Apr-08-2012! That is important for liturgic year calculations. Test script: --- Expected result: Apr-08-2012 Actual result: -- Apr-07-2012 -- Edit this bug report at https://bugs.php.net/bug.php?id=63047&edit=1
[PHP-BUG] Bug #63048 [NEW]: zip extension crashes on zip_close with zlib 1.2.7 (works fine in zlib 1.2.3)
From: kaplanlior at gmail dot com Operating system: PHP version: 5.4.6 Package: Zlib related Bug Type: Bug Bug description:zip extension crashes on zip_close with zlib 1.2.7 (works fine in zlib 1.2.3) Description: I've built zip extension dynamically against zlib 1.2.3, but when having zlib 1.2.7 in the execution environment, the extension crashes: /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7fd04e24d4f0] /usr/lib/x86_64-linux-gnu/libz.so.1(+0x3182) [0x7fd04ddec182] /usr/lib/x86_64-linux-gnu/libz.so.1(+0x377d) [0x7fd04ddec77d] /usr/lib/x86_64-linux-gnu/libz.so.1(deflate+0x107) [0x7fd04dded7f7] /usr/local/zend/lib/php_extensions/zip.so(zip_close+0xbb8) [0x7fd04b542fa8] /usr/local/zend/lib/php_extensions/zip.so(+0x8c02) [0x7fd04b53ec02] /usr/local/zend/gui/lighttpd/sbin/php() [0x689875] /usr/local/zend/gui/lighttpd/sbin/php(execute+0x1ce) [0x68f80e] /usr/local/zend/gui/lighttpd/sbin/php(zend_execute_scripts+0x159) [0x65bbd9] /usr/local/zend/gui/lighttpd/sbin/php(php_execute_script+0x1b8) [0x5feca8] /usr/local/zend/gui/lighttpd/sbin/php() [0x70418a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fd04e239ead] /usr/local/zend/gui/lighttpd/sbin/php() [0x43631a] Notice that most linux distributions are in the process to switch from 1.2.3 to 1.2.7. -- Edit bug report at https://bugs.php.net/bug.php?id=63048&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63048&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63048&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63048&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63048&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63048&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63048&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63048&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63048&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63048&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63048&r=support Expected behavior: https://bugs.php.net/fix.php?id=63048&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63048&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63048&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63048&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63048&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63048&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63048&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63048&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63048&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63048&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63048&r=mysqlcfg
Bug #61634 [Opn->Csd]: Test ext\sockets\tests\socket_listen-wrongparams.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61634&edit=1 ID: 61634 Updated by: larue...@php.net Reported by:a...@php.net Summary:Test ext\sockets\tests\socket_listen-wrongparams.phpt fails -Status: Open +Status: Closed Type: Bug Package:Sockets related Operating System: Windows PHP Version:Irrelevant -Assigned To: +Assigned To:laruence Block user comment: N Private report: N Previous Comments: [2012-09-09 10:19:55] reeze dot xia at gmail dot com This could be closed... [2012-04-10 11:19:02] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=c4676ee99f5381de502cd6544a9c42a25b53b933 Log: Fixed bug #61634 Test ext\sockets\tests\socket_listen-wrongparams.phpt fails [2012-04-10 02:00:26] mattfic...@php.net The patch works for me on Windows 7 and Gentoo Linux (x86 & x64) on php-5-3-r0f180a6. [2012-04-05 14:05:18] a...@php.net The patch disables this test on windows as unix sockets are not available there. [2012-04-05 14:04:40] a...@php.net The following patch has been added/updated: Patch Name: 61634.diff Revision: 1333634680 URL: https://bugs.php.net/patch-display.php?bug=61634&patch=61634.diff&revision=1333634680 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=61634 -- Edit this bug report at https://bugs.php.net/bug.php?id=61634&edit=1
Bug #61634 [Com]: Test ext\sockets\tests\socket_listen-wrongparams.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61634&edit=1 ID: 61634 Comment by: reeze dot xia at gmail dot com Reported by:a...@php.net Summary:Test ext\sockets\tests\socket_listen-wrongparams.phpt fails Status: Open Type: Bug Package:Sockets related Operating System: Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This could be closed... Previous Comments: [2012-04-10 11:19:02] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=c4676ee99f5381de502cd6544a9c42a25b53b933 Log: Fixed bug #61634 Test ext\sockets\tests\socket_listen-wrongparams.phpt fails [2012-04-10 02:00:26] mattfic...@php.net The patch works for me on Windows 7 and Gentoo Linux (x86 & x64) on php-5-3-r0f180a6. [2012-04-05 14:05:18] a...@php.net The patch disables this test on windows as unix sockets are not available there. [2012-04-05 14:04:40] a...@php.net The following patch has been added/updated: Patch Name: 61634.diff Revision: 1333634680 URL: https://bugs.php.net/patch-display.php?bug=61634&patch=61634.diff&revision=1333634680 [2012-04-05 12:28:58] a...@php.net Description: Test diff: 004+ Warning: socket_create(): Unable to create socket [0]: An address incompatible with the requested protocol was used. 005+ in C:\php-sdk\php53\vc9\x86\php-src\ext\sockets\tests\socket_listen-wrongparams.php on line 3 004- Warning: socket_listen(): unable to listen on socket [%d]: Invalid argument in %s on line %d 005- bool(false) 006+ 007+ Warning: socket_listen() expects parameter 1 to be resource, boolean given in C:\php-sdk\php53\vc9\x86\php-src\ext\sockets\tests\socket_listen-wrongparams.php on line 4 008+ NULL Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61634&edit=1
Bug #55671 [Com]: clean up the php 6 references in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55671&edit=1
ID: 55671
Comment by: reeze dot xia at gmail dot com
Reported by:tyr...@php.net
Summary:clean up the php 6 references in run-tests.php
Status: Open
Type: Bug
Package:Testing related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Yes,
I'm not saying that is a php6's feature.
I mean the outmost "if (PHP_MAJOR_VERSION < 6)â checking is not accurate
since PHP6 is going nowhere. That checking is useful in < 5.4 but not 6 :)
This issue was related to PHP6 cleanup,
so I mention that here.
Previous Comments:
[2012-09-09 09:42:15] larue...@php.net
I really don't understand your point. did you read the codes carefully?
it's not a php 6 specifc test, it's about to generate a warning about safe_mode.
it has nothing to do with php 6. 5.2 5.3 still have safe_mode. then
MAJOR_VERSOIN
of them will meet that condition..
[2012-09-09 09:31:35] reeze dot xia at gmail dot com
PHP6 didn't exist so that test was useless, as tyrael said,
safe_mode have been removed with 5.4.
[2012-09-09 09:05:29] larue...@php.net
"MAJOR_VERSION < 6" has nothing to do with PHP 6, what do you expected?
MAJOR_VERSION <= 5?
[2012-09-08 14:57:11] reeze dot xia at gmail dot com
Do we still have the problem?
I saw only one place have php6 specific test in run-tests.php
if (PHP_MAJOR_VERSION < 6) {
ini_set('magic_quotes_runtime',0); // this would break tests by modifying
EXPECT sections
if (ini_get('safe_mode')) {
echo <<< SAFE_MODE_WARNING
[2011-09-13 06:38:52] s...@php.net
A number of phpt's still have the PHP 6 syntax. These would need to be updated
before the string type change is made to run-tests.php
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=55671
--
Edit this bug report at https://bugs.php.net/bug.php?id=55671&edit=1
[PHP-BUG] Bug #63047 [NEW]: Easter date is wrong
From: aschenaz at gmail dot com Operating system: Linux PHP version: 5.4.6 Package: Calendar related Bug Type: Bug Bug description:Easter date is wrong Description: Asking for Easter date function, it will result Apr-07-2012, but it should be Apr-08-2012! That is important for liturgic year calculations. Test script: --- Expected result: Apr-08-2012 Actual result: -- Apr-07-2012 -- Edit bug report at https://bugs.php.net/bug.php?id=63047&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63047&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63047&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63047&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63047&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63047&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63047&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63047&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63047&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63047&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63047&r=support Expected behavior: https://bugs.php.net/fix.php?id=63047&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63047&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63047&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63047&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63047&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63047&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63047&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63047&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63047&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63047&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63047&r=mysqlcfg
Bug #55671 [Opn]: clean up the php 6 references in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55671&edit=1
ID: 55671
Updated by: larue...@php.net
Reported by:tyr...@php.net
Summary:clean up the php 6 references in run-tests.php
Status: Open
Type: Bug
Package:Testing related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I really don't understand your point. did you read the codes carefully?
it's not a php 6 specifc test, it's about to generate a warning about safe_mode.
it has nothing to do with php 6. 5.2 5.3 still have safe_mode. then
MAJOR_VERSOIN
of them will meet that condition..
Previous Comments:
[2012-09-09 09:31:35] reeze dot xia at gmail dot com
PHP6 didn't exist so that test was useless, as tyrael said,
safe_mode have been removed with 5.4.
[2012-09-09 09:05:29] larue...@php.net
"MAJOR_VERSION < 6" has nothing to do with PHP 6, what do you expected?
MAJOR_VERSION <= 5?
[2012-09-08 14:57:11] reeze dot xia at gmail dot com
Do we still have the problem?
I saw only one place have php6 specific test in run-tests.php
if (PHP_MAJOR_VERSION < 6) {
ini_set('magic_quotes_runtime',0); // this would break tests by modifying
EXPECT sections
if (ini_get('safe_mode')) {
echo <<< SAFE_MODE_WARNING
[2011-09-13 06:38:52] s...@php.net
A number of phpt's still have the PHP 6 syntax. These would need to be updated
before the string type change is made to run-tests.php
[2011-09-12 11:30:19] tyr...@php.net
Description:
there are mentions and special cases for working with php6, which isn't valid
anymore.
we should remove those(unicode string/binary string types), and there are some,
which should be enabled for >= 504000:
magic_quotes, safe_mode check, as those are removed with 5.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=55671&edit=1
Bug #55379 [Opn->Fbk]: can't iterate multidimensional array when referring to an object inside closure
Edit report at https://bugs.php.net/bug.php?id=55379&edit=1
ID: 55379
Updated by: larue...@php.net
Reported by:rsk82 at live dot com
Summary:can't iterate multidimensional array when referring
to an object inside closure
-Status: Open
+Status: Feedback
Type: Bug
Package:Class/Object related
Operating System: Windows XP SP3
PHP Version:5.3.7
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce on windows
Previous Comments:
[2012-09-08 15:29:55] reeze dot xia at gmail dot com
Hi rsk82,
please try lastest version,
from the follow result,
it it didn't crash on Linux, but the result output changed. so it
might been fixed already.
please refer to: http://3v4l.org/NUtav
[2011-08-19 16:33:19] rsk82 at live dot com
I nowadays released 5.3.7 this bug wasn't repaired.
[2011-08-07 14:50:33] rsk82 at live dot com
Description:
affected versions:
php-5.3.6-Win32-VC9-x86
php-5.3.7RC4-Win32-VC9-x86
php-5.3-ts-windows-vc9-x86-r314352
php-5.3-ts-windows-vc9-x86-r314419
php-5.4-ts-windows-vc9-x86-r314420
operating system:
Windows XP SP3
description in code
Test script:
---
' referenced memory at ''.
// #The memory could not be read.
// #Click OK to terminate the program.
// No error shows up in console, sometimes script stops without error but
sometimes executes like nothing is happening.
$test_data3 = array(array('one','two','three'),array('four','five','six'));
// error in PHP console:
// Fatal error: Call to a member function show_message() on a non-object in
c:\scripts\found-error.php on line xx
// values one two three are displayed, four five and six are ommitted.
class myClass {
function iterate_multidim_array($array) {
array_walk_recursive($array,function(&$val,$key,&$obj) {
$obj->show_message($val);
},$this);
}
function show_message($msg) {
echo $msg."\n";
}
}
echo phpversion()."\n\n";
$myInstance = new MyClass();
$myInstance-> iterate_multidim_array($test_data3);
?>
Expected result:
see no errors
Actual result:
--
comments in code
--
Edit this bug report at https://bugs.php.net/bug.php?id=55379&edit=1
Bug #55671 [Com]: clean up the php 6 references in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55671&edit=1
ID: 55671
Comment by: reeze dot xia at gmail dot com
Reported by:tyr...@php.net
Summary:clean up the php 6 references in run-tests.php
Status: Open
Type: Bug
Package:Testing related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
PHP6 didn't exist so that test was useless, as tyrael said,
safe_mode have been removed with 5.4.
Previous Comments:
[2012-09-09 09:05:29] larue...@php.net
"MAJOR_VERSION < 6" has nothing to do with PHP 6, what do you expected?
MAJOR_VERSION <= 5?
[2012-09-08 14:57:11] reeze dot xia at gmail dot com
Do we still have the problem?
I saw only one place have php6 specific test in run-tests.php
if (PHP_MAJOR_VERSION < 6) {
ini_set('magic_quotes_runtime',0); // this would break tests by modifying
EXPECT sections
if (ini_get('safe_mode')) {
echo <<< SAFE_MODE_WARNING
[2011-09-13 06:38:52] s...@php.net
A number of phpt's still have the PHP 6 syntax. These would need to be updated
before the string type change is made to run-tests.php
[2011-09-12 11:30:19] tyr...@php.net
Description:
there are mentions and special cases for working with php6, which isn't valid
anymore.
we should remove those(unicode string/binary string types), and there are some,
which should be enabled for >= 504000:
magic_quotes, safe_mode check, as those are removed with 5.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=55671&edit=1
Bug #55671 [Opn]: clean up the php 6 references in run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55671&edit=1
ID: 55671
Updated by: larue...@php.net
Reported by:tyr...@php.net
Summary:clean up the php 6 references in run-tests.php
Status: Open
Type: Bug
Package:Testing related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
"MAJOR_VERSION < 6" has nothing to do with PHP 6, what do you expected?
MAJOR_VERSION <= 5?
Previous Comments:
[2012-09-08 14:57:11] reeze dot xia at gmail dot com
Do we still have the problem?
I saw only one place have php6 specific test in run-tests.php
if (PHP_MAJOR_VERSION < 6) {
ini_set('magic_quotes_runtime',0); // this would break tests by modifying
EXPECT sections
if (ini_get('safe_mode')) {
echo <<< SAFE_MODE_WARNING
[2011-09-13 06:38:52] s...@php.net
A number of phpt's still have the PHP 6 syntax. These would need to be updated
before the string type change is made to run-tests.php
[2011-09-12 11:30:19] tyr...@php.net
Description:
there are mentions and special cases for working with php6, which isn't valid
anymore.
we should remove those(unicode string/binary string types), and there are some,
which should be enabled for >= 504000:
magic_quotes, safe_mode check, as those are removed with 5.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=55671&edit=1
