Bug #61383 [Opn->Nab]: can't define type of var in class method
Edit report at https://bugs.php.net/bug.php?id=61383&edit=1
ID: 61383
Updated by: ras...@php.net
Reported by:keryax at ya dot ru
Summary:can't define type of var in class method
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: windows server 2003 R2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
PHP does not have scalar type hints.
public static function lol(integer $A)
That says that you want $A to be an instance of Class integer. That's
completely
distinct from the scalar integer type.
Try this:
class integer { }
class omg{
public static function lol(integer $A){
return true;
}
}
echo omg::lol(new integer);
Previous Comments:
[2012-03-14 06:45:28] keryax at ya dot ru
Description:
I've got strange error:
Catchable fatal error: Argument 1 passed to omg::lol() must be an instance of
integer, integer given
When I've replaced "integer" to "int", I've got:
Catchable fatal error: Argument 1 passed to omg::lol() must be an instance of
int, integer given
Test script:
---
class omg{
public static function lol(integer $A){
return true;
}
}
echo omg::lol(123);
Expected result:
calling the method
--
captain obvious
Actual result:
--
Catchable fatal error
--
Edit this bug report at https://bugs.php.net/bug.php?id=61383&edit=1
[PHP-BUG] Bug #61383 [NEW]: can't define type of var in class method
From:
Operating system: windows server 2003 R2
PHP version: 5.4.0
Package: Scripting Engine problem
Bug Type: Bug
Bug description:can't define type of var in class method
Description:
I've got strange error:
Catchable fatal error: Argument 1 passed to omg::lol() must be an instance
of integer, integer given
When I've replaced "integer" to "int", I've got:
Catchable fatal error: Argument 1 passed to omg::lol() must be an instance
of int, integer given
Test script:
---
class omg{
public static function lol(integer $A){
return true;
}
}
echo omg::lol(123);
Expected result:
calling the method
--
captain obvious
Actual result:
--
Catchable fatal error
--
Edit bug report at https://bugs.php.net/bug.php?id=61383&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61383&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61383&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61383&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61383&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61383&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61383&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61383&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61383&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61383&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61383&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61383&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61383&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61383&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61383&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61383&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61383&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61383&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61383&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61383&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61383&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61383&r=mysqlcfg
Req #61382 [Opn]: need a function class_rename
Edit report at https://bugs.php.net/bug.php?id=61382&edit=1
ID: 61382
User updated by:todesw1nd at hotmail dot com
Reported by:todesw1nd at hotmail dot com
Summary:need a function class_rename
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: independent
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
tiny error in code example:
class Wrapper_Car extends Base_Car <- this should be more correct
the class name for all "real" cars is Wrapper_Car, even if i buy a third one
Previous Comments:
[2012-03-14 06:37:12] todesw1nd at hotmail dot com
Description:
this is OOP related and maybe targets to AOP.
Since i found a quick & dirty solution for myself using eval() in my framework
it is not urgent, but would be nice to have to no longer need it as it is not
used on any other parts currently.
The problem itself:
Lets say we have two cars and don't care about which one we drive, we just want
to use one of it and a friend should decide which one by selecting it.
In PHP i now have to use a wrapper class for each of the two cars with the same
name, e.g. Wrapper_Car and a base class that is extended with their
functionality, e.g. Base_Car. I do have a mess now as different cars can't have
the same file name due to the default autoloader.
Test script:
---
file base_car.php:
abstract class Base_Car
{
abstract public function drive();
}
file wrapper_car1.php:
class Wrapper_Car
{
public function drive
{
// Lets drive it ^^
}
}
file wrapper_car2.php:
same content as wrapper_car1.php but slightly other implementation inside the
methods of the class
Expected result:
I would like to have a function like this:
class_rename($class_name, $class_newname);
So i can autoload the car class i want to use, e.g. wrapper_car1.php and have
the class called Wrapper_Car1 and then rename it to Wrapper_Car as it is the
selected car i want to drive with.
Important: It would be ok if the autoloader tries to load the first param
$class_name if it does not exist, but it should never ever do it for the second
parameter as e.g. class_alias does it currently and is therefore useless for
this case.
Actual result:
--
As said before i currently use a one liner eval that sets the namespaces and
creates the renamed class based on the earlier loaded one to emulate this
behavior and i think that is little dirty :]
Thanks for reading this and it would be awesome to have such a functionality in
a later PHP version. If you see it from another point of view it would be nice
to see why.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61382&edit=1
[PHP-BUG] Req #61382 [NEW]: need a function class_rename
From:
Operating system: independent
PHP version: 5.4.0
Package: SPL related
Bug Type: Feature/Change Request
Bug description:need a function class_rename
Description:
this is OOP related and maybe targets to AOP.
Since i found a quick & dirty solution for myself using eval() in my
framework it is not urgent, but would be nice to have to no longer need it
as it is not used on any other parts currently.
The problem itself:
Lets say we have two cars and don't care about which one we drive, we just
want to use one of it and a friend should decide which one by selecting
it.
In PHP i now have to use a wrapper class for each of the two cars with the
same name, e.g. Wrapper_Car and a base class that is extended with their
functionality, e.g. Base_Car. I do have a mess now as different cars can't
have the same file name due to the default autoloader.
Test script:
---
file base_car.php:
abstract class Base_Car
{
abstract public function drive();
}
file wrapper_car1.php:
class Wrapper_Car
{
public function drive
{
// Lets drive it ^^
}
}
file wrapper_car2.php:
same content as wrapper_car1.php but slightly other implementation inside
the methods of the class
Expected result:
I would like to have a function like this:
class_rename($class_name, $class_newname);
So i can autoload the car class i want to use, e.g. wrapper_car1.php and
have the class called Wrapper_Car1 and then rename it to Wrapper_Car as it
is the selected car i want to drive with.
Important: It would be ok if the autoloader tries to load the first param
$class_name if it does not exist, but it should never ever do it for the
second parameter as e.g. class_alias does it currently and is therefore
useless for this case.
Actual result:
--
As said before i currently use a one liner eval that sets the namespaces
and creates the renamed class based on the earlier loaded one to emulate
this behavior and i think that is little dirty :]
Thanks for reading this and it would be awesome to have such a
functionality in a later PHP version. If you see it from another point of
view it would be nice to see why.
--
Edit bug report at https://bugs.php.net/bug.php?id=61382&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61382&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61382&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61382&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61382&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61382&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61382&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61382&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61382&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61382&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61382&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61382&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61382&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61382&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61382&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61382&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61382&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61382&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61382&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61382&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61382&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61382&r=mysqlcfg
Bug #49151 [Com]: relocation must bind locally
Edit report at https://bugs.php.net/bug.php?id=49151&edit=1 ID: 49151 Comment by: sergei dot solomonov at gmail dot com Reported by:tech at uscki dot nl Summary:relocation must bind locally Status: Open Type: Bug Package:Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Try this: ext/date/php_date.c:511 (line 508, for php 5.4) -zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; +static zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; Previous Comments: [2010-09-13 23:45:24] brentk at birs dot ca I'm getting the same problem with PHP 5.3.3 on Solaris 10 (x64), gcc 4.3.3. The compile dies at php_date.o with the same message as the original post. If I remove the "-fvisibility=hidden" part from configure, this doesn't happen. [2010-05-24 17:20:11] dbakyle at gmail dot com I've removed the -fvisibility=hidden from the Makefile and tried the make again. The process is still failing on glob_wrapper.lo I'm using 4.1.2 of gcc and 2.6.18-92.1.22.0.1 of Red Hat. [2009-08-17 09:42:07] j...@php.net It should be as simple as adding 'static' in the macro ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway.. [2009-08-14 23:13:32] tech at uscki dot nl Yeah, got it compiling! I removed "-fvisibility=hidden" from the Makefile after running ./configure, guess that boils down to the same result, though your suggestion is a bit tidier. Compiler: gcc (GCC) 4.0.1 Thanks for all your help! [2009-08-14 21:54:04] nlop...@php.net sorry, I forgot to say that before ./configure you must run ./buildconf 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=49151 -- Edit this bug report at https://bugs.php.net/bug.php?id=49151&edit=1
Bug #61380 [Nab]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1
ID: 61380
User updated by:thephpguru at hotmail dot com
Reported by:thephpguru at hotmail dot com
Summary:XMLRPC Return Data Failure
Status: Not a bug
Type: Bug
Package:XML related
Operating System: Fedora 13
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Dopppee. My complex script gets reduced to a simpler script. I will
try it your way.
Previous Comments:
[2012-03-14 02:19:06] ahar...@php.net
I don't really see how bug #46699 is related, besides being another xml_parse()
bug -- it was a crasher related to namespace-aware parsers, and your issue
involves neither crashing nor namespaces.
The more I look at this, the less it looks like a bug in PHP. This script
behaves
as expected (outputting "Bare text content" and "", without
the "truncation" you reported separately in ##php:
Bare text content
EOX;
function cdata_handler($parser, $data) {
if (trim($data)) { // ignore whitespace
var_dump($data);
}
}
$parser = xml_parser_create();
xml_set_character_data_handler($parser, 'cdata_handler');
xml_parse($parser, $xml);
?>
You should follow this up with a support channel, such as ##php or those listed
at
http://www.php.net/support.php, as this bug system is not a support forum. If
you
are able to reduce this to a self-contained, short example (such as that above)
that shows a clear regression from PHP 5.2 to 5.3, please reopen this bug with
that example.
Thank you for your interest in PHP.
[2012-03-14 02:00:47] thephpguru at hotmail dot com
My problem is very similar to bug 46699. And that is what the MAKE_TEST file
shows.
https://freshsoftware.dyndns.info/~freshsoftware/scripts_for_sale/usps/make_test.txt
[2012-03-14 01:57:58] thephpguru at hotmail dot com
I can not make a complex script any shorter. In short the open_url function on
line 100 connects to the USPS server. The startElement function on line 117
sets the array, and names the XML tree ID structure, The endElement function
set the end of the tree info, and the CharacterDataHandler function captures
the data between start and end functions. The xml_set_character_data_handler
function is then used to read the data.
But the data is getting turncated.
[2012-03-14 01:47:04] ahar...@php.net
I saw that. A (much) shorter, standalone reproduction script is required.
[2012-03-14 01:44:21] thephpguru at hotmail dot com
A sample code is:
http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61380
--
Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Bug #61380 [Opn->Nab]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1
ID: 61380
Updated by: ahar...@php.net
Reported by:thephpguru at hotmail dot com
Summary:XMLRPC Return Data Failure
-Status: Open
+Status: Not a bug
Type: Bug
-Package:XMLRPC-EPI related
+Package:XML related
Operating System: Fedora 13
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I don't really see how bug #46699 is related, besides being another xml_parse()
bug -- it was a crasher related to namespace-aware parsers, and your issue
involves neither crashing nor namespaces.
The more I look at this, the less it looks like a bug in PHP. This script
behaves
as expected (outputting "Bare text content" and "", without
the "truncation" you reported separately in ##php:
Bare text content
EOX;
function cdata_handler($parser, $data) {
if (trim($data)) { // ignore whitespace
var_dump($data);
}
}
$parser = xml_parser_create();
xml_set_character_data_handler($parser, 'cdata_handler');
xml_parse($parser, $xml);
?>
You should follow this up with a support channel, such as ##php or those listed
at
http://www.php.net/support.php, as this bug system is not a support forum. If
you
are able to reduce this to a self-contained, short example (such as that above)
that shows a clear regression from PHP 5.2 to 5.3, please reopen this bug with
that example.
Thank you for your interest in PHP.
Previous Comments:
[2012-03-14 02:00:47] thephpguru at hotmail dot com
My problem is very similar to bug 46699. And that is what the MAKE_TEST file
shows.
https://freshsoftware.dyndns.info/~freshsoftware/scripts_for_sale/usps/make_test.txt
[2012-03-14 01:57:58] thephpguru at hotmail dot com
I can not make a complex script any shorter. In short the open_url function on
line 100 connects to the USPS server. The startElement function on line 117
sets the array, and names the XML tree ID structure, The endElement function
set the end of the tree info, and the CharacterDataHandler function captures
the data between start and end functions. The xml_set_character_data_handler
function is then used to read the data.
But the data is getting turncated.
[2012-03-14 01:47:04] ahar...@php.net
I saw that. A (much) shorter, standalone reproduction script is required.
[2012-03-14 01:44:21] thephpguru at hotmail dot com
A sample code is:
http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps
[2012-03-14 01:23:16] ahar...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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=61380
--
Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Bug #61380 [Opn]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 User updated by:thephpguru at hotmail dot com Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure Status: Open Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: My problem is very similar to bug 46699. And that is what the MAKE_TEST file shows. https://freshsoftware.dyndns.info/~freshsoftware/scripts_for_sale/usps/make_test.txt Previous Comments: [2012-03-14 01:57:58] thephpguru at hotmail dot com I can not make a complex script any shorter. In short the open_url function on line 100 connects to the USPS server. The startElement function on line 117 sets the array, and names the XML tree ID structure, The endElement function set the end of the tree info, and the CharacterDataHandler function captures the data between start and end functions. The xml_set_character_data_handler function is then used to read the data. But the data is getting turncated. [2012-03-14 01:47:04] ahar...@php.net I saw that. A (much) shorter, standalone reproduction script is required. [2012-03-14 01:44:21] thephpguru at hotmail dot com A sample code is: http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps [2012-03-14 01:23:16] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-03-14 01:12:16] thephpguru at hotmail dot com My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini 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=61380 -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Bug #61380 [Fbk->Opn]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 User updated by:thephpguru at hotmail dot com Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure -Status: Feedback +Status: Open Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I can not make a complex script any shorter. In short the open_url function on line 100 connects to the USPS server. The startElement function on line 117 sets the array, and names the XML tree ID structure, The endElement function set the end of the tree info, and the CharacterDataHandler function captures the data between start and end functions. The xml_set_character_data_handler function is then used to read the data. But the data is getting turncated. Previous Comments: [2012-03-14 01:47:04] ahar...@php.net I saw that. A (much) shorter, standalone reproduction script is required. [2012-03-14 01:44:21] thephpguru at hotmail dot com A sample code is: http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps [2012-03-14 01:23:16] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-03-14 01:12:16] thephpguru at hotmail dot com My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini [2012-03-14 00:36:05] thephpguru at hotmail dot com Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Req #61366 [Com]: DateInterval should support weeks and days combined
Edit report at https://bugs.php.net/bug.php?id=61366&edit=1 ID: 61366 Comment by: uramihsayibok at gmail dot com Reported by:evert at rooftopsolutions dot nl Summary:DateInterval should support weeks and days combined Status: Open Type: Feature/Change Request Package:Date/time related Operating System: Any PHP Version:5.3.10 Block user comment: N Private report: N New Comment: ISO 8601 doesn't allow mixing weeks with anything else. If you need both then just do the math: 7 * weeks + days Previous Comments: [2012-03-12 21:53:19] evert at rooftopsolutions dot nl Description: The DateInterval should support specifying weeks and days at the same time. This is documented to not be supported, but this is imho silly and confusing. Test script: --- d; ?> Expected result: 8 Actual result: -- 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61366&edit=1
Bug #61380 [Opn->Fbk]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 Updated by: ahar...@php.net Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure -Status: Open +Status: Feedback Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I saw that. A (much) shorter, standalone reproduction script is required. Previous Comments: [2012-03-14 01:44:21] thephpguru at hotmail dot com A sample code is: http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps [2012-03-14 01:23:16] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-03-14 01:12:16] thephpguru at hotmail dot com My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini [2012-03-14 00:36:05] thephpguru at hotmail dot com Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Bug #61356 [Csd->Nab]: error_reporting always reports E_STRICT
Edit report at https://bugs.php.net/bug.php?id=61356&edit=1
ID: 61356
Updated by: ahar...@php.net
Reported by:dave dot kimble at gmx dot com
Summary:error_reporting always reports E_STRICT
-Status: Closed
+Status: Not a bug
Type: Bug
Package:PHP options/info functions
Operating System: Windows 7 Ult 32
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
No worries, thanks.
Previous Comments:
[2012-03-14 01:42:52] dave dot kimble at gmx dot com
AfterLogic say they are very sorry and their code DOES contain error_reporting
in 2 scripts for debug purposes that should be commented out.
Sorry to waste your time.
CLOSED
[2012-03-13 03:36:23] dave dot kimble at gmx dot com
Here is a test script:
' .
'php ini loaded = ' . php_ini_loaded_file() . '' .
'error_reporting = ' . ini_get('error_reporting') . '' .
'display_errors = ' . ini_get('display_errors') . '' .
'end');
?>
Here is the output:
script = /webmail/test.php
php ini loaded = C:\PHP\php.ini
error_reporting = 22527
display_errors =
end
22527 = (32767 - 8192 - 2048) = E_ALL & ~E_DEPRECATED & ~E_STRICT
so something is the matter with error_reporting because E_STRICT messages ARE
appearing.
The display_errors is WRONG because in C:\PHP\php.ini it is set to:
display_errors = Off
The php.ini file is at http://www.peakoil.org.au/php.ini
[2012-03-13 01:35:41] ras...@php.net
You are missing something here. This works fine for everyone else. Hard to tell
from here what it is though.
[2012-03-13 01:10:07] dave dot kimble at gmx dot com
Yes, the correct file was identified by phpinfo as C:/PHP/php.ini .
Yes, the web server was restarted afterwards.
I also inserted error_reporting into /webmail/index.php to no effect.
If I add a line 2 to /webmail/index.php :
http://php.net/manual/en/function.error-reporting.php for v5.4.0 making
E_STRICT part of E_ALL.
So there has been a change in this very area where I am finding a problem.
[2012-03-12 21:45:42] paj...@php.net
create a phpinfo.php with:
https://bugs.php.net/bug.php?id=61356
--
Edit this bug report at https://bugs.php.net/bug.php?id=61356&edit=1
Bug #61380 [Fbk->Opn]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 User updated by:thephpguru at hotmail dot com Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure -Status: Feedback +Status: Open Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: A sample code is: http://freshsoftware.dyndns.info/usps/usps_xml_carrier_pickup_live.phps Previous Comments: [2012-03-14 01:23:16] ahar...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-03-14 01:12:16] thephpguru at hotmail dot com My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini [2012-03-14 00:36:05] thephpguru at hotmail dot com Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Bug #61356 [Opn->Csd]: error_reporting always reports E_STRICT
Edit report at https://bugs.php.net/bug.php?id=61356&edit=1
ID: 61356
User updated by:dave dot kimble at gmx dot com
Reported by:dave dot kimble at gmx dot com
Summary:error_reporting always reports E_STRICT
-Status: Open
+Status: Closed
Type: Bug
Package:PHP options/info functions
Operating System: Windows 7 Ult 32
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
AfterLogic say they are very sorry and their code DOES contain error_reporting
in 2 scripts for debug purposes that should be commented out.
Sorry to waste your time.
CLOSED
Previous Comments:
[2012-03-13 03:36:23] dave dot kimble at gmx dot com
Here is a test script:
' .
'php ini loaded = ' . php_ini_loaded_file() . '' .
'error_reporting = ' . ini_get('error_reporting') . '' .
'display_errors = ' . ini_get('display_errors') . '' .
'end');
?>
Here is the output:
script = /webmail/test.php
php ini loaded = C:\PHP\php.ini
error_reporting = 22527
display_errors =
end
22527 = (32767 - 8192 - 2048) = E_ALL & ~E_DEPRECATED & ~E_STRICT
so something is the matter with error_reporting because E_STRICT messages ARE
appearing.
The display_errors is WRONG because in C:\PHP\php.ini it is set to:
display_errors = Off
The php.ini file is at http://www.peakoil.org.au/php.ini
[2012-03-13 01:35:41] ras...@php.net
You are missing something here. This works fine for everyone else. Hard to tell
from here what it is though.
[2012-03-13 01:10:07] dave dot kimble at gmx dot com
Yes, the correct file was identified by phpinfo as C:/PHP/php.ini .
Yes, the web server was restarted afterwards.
I also inserted error_reporting into /webmail/index.php to no effect.
If I add a line 2 to /webmail/index.php :
http://php.net/manual/en/function.error-reporting.php for v5.4.0 making
E_STRICT part of E_ALL.
So there has been a change in this very area where I am finding a problem.
[2012-03-12 21:45:42] paj...@php.net
create a phpinfo.php with:
https://bugs.php.net/bug.php?id=61356
--
Edit this bug report at https://bugs.php.net/bug.php?id=61356&edit=1
Req #39467 [Opn->Wfx]: Expaned Class members to allow setting of a read only value at runtime
Edit report at https://bugs.php.net/bug.php?id=39467&edit=1
ID: 39467
Updated by: ahar...@php.net
Reported by:kevin at metalaxe dot com
Summary:Expaned Class members to allow setting of a read
only value at runtime
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: *
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
A private field plus an accessor with the desired visibility would work fine
here
without needing a language extension.
Closing won't fix.
Previous Comments:
[2012-03-14 01:29:58] uramihsayibok at gmail dot com
If you need to define the "constant" in your constructor then what you have
isn't a constant. So if you don't
want it public then don't make it public.
class parser {
private $_magic_quotes = false;
function __construct() { $this->_magic_quotes = /* etc */; }
}
Otherwise you have to define the constant outside the class and if that's the
case then you might as well use
define(). If you're really hung up on the class constant syntax then you can
define("MAGIC_QUOTES", /* etc */);
class parser {
const MAGIC_QUOTES = MAGIC_QUOTES;
}
Side notes:
1. Though this isn't the place for discussion, if it were I'd talk about how a
global constant for this
particular example makes more sense anyways.
2. Since magic_quotes *and its functions* are going way the best way to check
for it is
(function_exists("get_magic_quotes_gpc") && get_magic_quotes_gpc())
[2006-11-10 23:49:45] kevin at metalaxe dot com
There is a typo in my example code above.
public my_stripslashes( $str )
{
if( self::magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
should be
public my_stripslashes( $str )
{
if( $this->magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
[2006-11-10 23:47:46] kevin at metalaxe dot com
Description:
Since http://bugs.php.net/bug.php?id=39466 was shot down, PHP is in need of a
method to which we can set class member variables as read-only during runtime
to prevent changing of values that are critically important for script
execution.
I would like to use a class constant for this but, because it cannot be
assigned a value at runtime, it is impossible to do so. The reproduce code is
an example of a value that I would like to set as read only. The scope of the
variable should not matter in this suggestion as it is practical that it would
need to be changed given a proper reason.
Reproduce code:
---
magic_quotes = (bool)get_magic_quotes_gpc();
}
public my_stripslashes( $str )
{
if( self::magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
public change_magic_quotes($to)
{
$this->magic_quotes = $to;
}
}
$parser = new parser();
//Returns stripped string
$stripped = $parser->my_stripslashes( 'Hi, there\'s a coke in the fridge' );
//Doesn't change the value of magic_quotes and flags an
//E_WARNING or E_NOTICE error.
$parser->change_magic_quotes( true );
?>
Expected result:
Hope to have it not allow the variable to be changed (ha, a constant, what a
silly notion) and pop an error of some kind to the parser.
Actual result:
--
Not implemented, thus values can be changed at any time as long as the variable
is within the visibility scope of calling party.
--
Edit this bug report at https://bugs.php.net/bug.php?id=39467&edit=1
Req #39467 [Com]: Expaned Class members to allow setting of a read only value at runtime
Edit report at https://bugs.php.net/bug.php?id=39467&edit=1
ID: 39467
Comment by: uramihsayibok at gmail dot com
Reported by:kevin at metalaxe dot com
Summary:Expaned Class members to allow setting of a read
only value at runtime
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
If you need to define the "constant" in your constructor then what you have
isn't a constant. So if you don't
want it public then don't make it public.
class parser {
private $_magic_quotes = false;
function __construct() { $this->_magic_quotes = /* etc */; }
}
Otherwise you have to define the constant outside the class and if that's the
case then you might as well use
define(). If you're really hung up on the class constant syntax then you can
define("MAGIC_QUOTES", /* etc */);
class parser {
const MAGIC_QUOTES = MAGIC_QUOTES;
}
Side notes:
1. Though this isn't the place for discussion, if it were I'd talk about how a
global constant for this
particular example makes more sense anyways.
2. Since magic_quotes *and its functions* are going way the best way to check
for it is
(function_exists("get_magic_quotes_gpc") && get_magic_quotes_gpc())
Previous Comments:
[2006-11-10 23:49:45] kevin at metalaxe dot com
There is a typo in my example code above.
public my_stripslashes( $str )
{
if( self::magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
should be
public my_stripslashes( $str )
{
if( $this->magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
[2006-11-10 23:47:46] kevin at metalaxe dot com
Description:
Since http://bugs.php.net/bug.php?id=39466 was shot down, PHP is in need of a
method to which we can set class member variables as read-only during runtime
to prevent changing of values that are critically important for script
execution.
I would like to use a class constant for this but, because it cannot be
assigned a value at runtime, it is impossible to do so. The reproduce code is
an example of a value that I would like to set as read only. The scope of the
variable should not matter in this suggestion as it is practical that it would
need to be changed given a proper reason.
Reproduce code:
---
magic_quotes = (bool)get_magic_quotes_gpc();
}
public my_stripslashes( $str )
{
if( self::magic_quotes === true )
{
$str = stripslashes( $str );
}
return $str;
}
public change_magic_quotes($to)
{
$this->magic_quotes = $to;
}
}
$parser = new parser();
//Returns stripped string
$stripped = $parser->my_stripslashes( 'Hi, there\'s a coke in the fridge' );
//Doesn't change the value of magic_quotes and flags an
//E_WARNING or E_NOTICE error.
$parser->change_magic_quotes( true );
?>
Expected result:
Hope to have it not allow the variable to be changed (ha, a constant, what a
silly notion) and pop an error of some kind to the parser.
Actual result:
--
Not implemented, thus values can be changed at any time as long as the variable
is within the visibility scope of calling party.
--
Edit this bug report at https://bugs.php.net/bug.php?id=39467&edit=1
Bug #61376 [Opn->Fbk]: saveHTML only allows one option element to have the selected attribute.
Edit report at https://bugs.php.net/bug.php?id=61376&edit=1
ID: 61376
Updated by: ahar...@php.net
Reported by:jrbeaure at uvm dot edu
Summary:saveHTML only allows one option element to have the
selected attribute.
-Status: Open
+Status: Feedback
Type: Bug
Package:DOM XML related
Operating System: Linux (Unknown Derivative)
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
This works fine for me:
loadXML('foobar');
foreach ($dom->getElementsByTagName('option') as $option) {
$option->removeAttribute('selected');
$option->setAttribute('selected', 'selected');
}
echo $dom->saveHTML();
?>
Previous Comments:
[2012-03-13 15:35:39] jrbeaure at uvm dot edu
I forgot to mention in the description my work around.
I use saveXML instead, which works. However, this also breaks my code because
the CDATA node markup in script tags cause the scripts to break in browsers,
regardless of whether it's the official standard. To get around this I used
preg_replace to surround the markup with javascript /*comment*/
markup.
[2012-03-13 15:30:33] jrbeaure at uvm dot edu
Description:
I've been having a very hard time trying to use the DOMDocument class for this
purpose, and it's taken me three days to figure out how to work around the bugs.
When loading elements from different selects:
If there is a presently selected option, I remove the selected attribute from
the option using the DOMElement removeAttribute method.
Then I use the DOMElement setAttribute method to set the attribute 'selected'
to the value 'selected'.
I do this for two different options that are children of two different select
elements.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61376&edit=1
Bug #61380 [Opn->Fbk]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 Updated by: ahar...@php.net Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure -Status: Open +Status: Feedback Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2012-03-14 01:12:16] thephpguru at hotmail dot com My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini [2012-03-14 00:36:05] thephpguru at hotmail dot com Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Req #61379 [Opn->Nab]: Set _SERVER['HTTPS'] to on for SPDY connections
Edit report at https://bugs.php.net/bug.php?id=61379&edit=1
ID: 61379
Updated by: ahar...@php.net
Reported by:rickard at 0x539 dot se
Summary:Set _SERVER['HTTPS'] to on for SPDY connections
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:Apache2 related
Operating System: Linux 2.6
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
It's going to be up to mod_spdy to set the relevant environment variable(s) in
Apache.
Previous Comments:
[2012-03-13 21:55:11] rickard at 0x539 dot se
Description:
When playing around with the mod_spdy Apache module it seems that the HTTPS key
in
the _SERVER variable is set to off. I'm not sure if this is the job for PHP or
SPDY but I thought I'd start here.
Test script:
---
http://code.google.com/p/mod-spdy/wiki/GettingStarted
Connect to the server and dump _SERVER */
var_dump($_SERVER);
Expected result:
["HTTPS"]=>
string(3) "On"
Actual result:
--
array(40) {
["REDIRECT_SPDY_VERSION"]=>
string(1) "2"
["SPDY_VERSION"]=>
string(1) "2"
..
["SERVER_PORT"]=>
string(3) "443"
..
["HTTPS"]=>
string(3) "Off"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61379&edit=1
Bug #61380 [Opn]: XMLRPC Return Data Failure
Edit report at https://bugs.php.net/bug.php?id=61380&edit=1 ID: 61380 User updated by:thephpguru at hotmail dot com Reported by:thephpguru at hotmail dot com Summary:XMLRPC Return Data Failure Status: Open Type: Bug Package:XMLRPC-EPI related Operating System: Fedora 13 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: My php.ini file can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/php.ini Previous Comments: [2012-03-14 00:36:05] thephpguru at hotmail dot com Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit this bug report at https://bugs.php.net/bug.php?id=61380&edit=1
Req #16119 [Opn->Wfx]: Swapping two elements of an array
Edit report at https://bugs.php.net/bug.php?id=16119&edit=1 ID: 16119 Updated by: ahar...@php.net Reported by:joho at webbplatsen dot se Summary:Swapping two elements of an array -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: All PHP Version:4.1.2 Block user comment: N Private report: N New Comment: Fair point. Not really convinced we need this in the language anyway: it's easy enough to implement in userspace. Previous Comments: [2012-03-14 00:53:05] uramihsayibok at gmail dot com You can do this in one statement with list(). list($ar[1], $ar[0]) = array($ar[0], $ar[1]); Note that due to how list() works you CANNOT use a shorthand of list($ar[1], $ar[0]) = $ar; [2002-03-16 18:52:05] joho at webbplatsen dot se I must be getting old, but I cannot seem to find a function that swaps the data of two array entries. Like so: $ar[0] = "second"; $ar[1] = "first"; array_swap ($ar, 0, 1); I have not overlooked the sort functions, that is not what I am after. But I may have overlooked other possibilities. Searching for "swap" in the PHP .CHM (fairly recent) yielded no hits. -- Edit this bug report at https://bugs.php.net/bug.php?id=16119&edit=1
Req #16119 [Com]: Swapping two elements of an array
Edit report at https://bugs.php.net/bug.php?id=16119&edit=1 ID: 16119 Comment by: uramihsayibok at gmail dot com Reported by:joho at webbplatsen dot se Summary:Swapping two elements of an array Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:4.1.2 Block user comment: N Private report: N New Comment: You can do this in one statement with list(). list($ar[1], $ar[0]) = array($ar[0], $ar[1]); Note that due to how list() works you CANNOT use a shorthand of list($ar[1], $ar[0]) = $ar; Previous Comments: [2002-03-16 18:52:05] joho at webbplatsen dot se I must be getting old, but I cannot seem to find a function that swaps the data of two array entries. Like so: $ar[0] = "second"; $ar[1] = "first"; array_swap ($ar, 0, 1); I have not overlooked the sort functions, that is not what I am after. But I may have overlooked other possibilities. Searching for "swap" in the PHP .CHM (fairly recent) yielded no hits. -- Edit this bug report at https://bugs.php.net/bug.php?id=16119&edit=1
[PHP-BUG] Bug #61380 [NEW]: XMLRPC Return Data Failure
From: Operating system: Fedora 13 PHP version: 5.3.10 Package: XMLRPC-EPI related Bug Type: Bug Bug description:XMLRPC Return Data Failure Description: Hello I am writing because I have a script that uses the XMLRPC functions. I have used the same scripts for about 3 years now with no problems. One example of the script in question can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/usps_xml_carrier_pickup_live.phps The application that runs this script can be found at: http://freshsoftware.dyndns.info/scripts_for_sale/usps/carrier_pickup_1.php?item_num=USPS-1565986&t=computer_software&software_title=php_usps_xml_carrier_pickup The problem with this script is that the delivery confirmation number BLAH collected from the function "CharacterDataHandler" and other $data is not being returned by the XML PARSE function or the data is broken up into different parts. For example read the confirmation number in the first set of lines then read the comfirmation number in the second set of lines. There are several other scripts on that site that also use the same XMLRPC functions and are failing in one way or another. I have used these scripts for about 3 years with out making changes. I had no problems with PHP-5.2.3 and earlier versions. I tried to install PHP-5.4.0 and the MAKE process failed. I then install PHP-5.3.10 but the XMLRPC functions all fail. A copy of the server Make Test is: http://freshsoftware.dyndns.info/scripts_for_sale/usps/make_test.txt Notice that there are 2 XML related bugs at the end of the report. I removed --enable-debug from my CONFIG but that does not solve the problem. Please help. My current config can be found at: http://freshsoftware.dyndns.info/php/ Please read the attached MAKE TEST file. Eric Williams Expected result: Unbroken data. Actual result: -- Data that is broken into different parts. -- Edit bug report at https://bugs.php.net/bug.php?id=61380&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61380&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61380&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61380&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61380&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61380&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61380&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61380&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61380&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61380&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61380&r=support Expected behavior: https://bugs.php.net/fix.php?id=61380&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61380&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61380&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61380&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61380&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61380&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61380&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61380&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61380&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61380&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61380&r=mysqlcfg
Req #26789 [Com]: NullPointerException desired
Edit report at https://bugs.php.net/bug.php?id=26789&edit=1 ID: 26789 Comment by: me at joshsera dot com Reported by:davidc at blesys dot com Summary:NullPointerException desired Status: Wont fix Type: Feature/Change Request Package:Feature/Change Request Operating System: (doesn't apply) PHP Version:5.0.0b3 (beta3) Block user comment: N Private report: N New Comment: The point of an NPE is so you can enclose code in a try/catch block instead of wrapping every statement in an if that tests for null. It makes for more readable code. Previous Comments: [2004-01-05 03:00:01] der...@php.net If you want to have "NULL" objects, test if an object is NULL before you call methods on it. There is no chance this will be implemented. [2004-01-04 18:23:05] davidc at blesys dot com Description: I desire a NullPointerException to be thrown, like in Java. Currently, a fatal error triggers, stopping my entire application. Many times an object may be null, but the application can continue. In addition, if an exception were thrown, I could trace it to see why the exception occured. Reproduce code: --- $j=null; $j->someMethod(); Expected result: Fatal error: Call to a member function someMethod() on a non-object in file.php on line 2 -- Edit this bug report at https://bugs.php.net/bug.php?id=26789&edit=1
[PHP-BUG] Req #61379 [NEW]: Set _SERVER['HTTPS'] to on for SPDY connections
From:
Operating system: Linux 2.6
PHP version: 5.3.10
Package: Apache2 related
Bug Type: Feature/Change Request
Bug description:Set _SERVER['HTTPS'] to on for SPDY connections
Description:
When playing around with the mod_spdy Apache module it seems that the HTTPS
key in
the _SERVER variable is set to off. I'm not sure if this is the job for PHP
or
SPDY but I thought I'd start here.
Test script:
---
http://code.google.com/p/mod-spdy/wiki/GettingStarted
Connect to the server and dump _SERVER */
var_dump($_SERVER);
Expected result:
["HTTPS"]=>
string(3) "On"
Actual result:
--
array(40) {
["REDIRECT_SPDY_VERSION"]=>
string(1) "2"
["SPDY_VERSION"]=>
string(1) "2"
..
["SERVER_PORT"]=>
string(3) "443"
..
["HTTPS"]=>
string(3) "Off"
}
--
Edit bug report at https://bugs.php.net/bug.php?id=61379&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61379&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61379&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61379&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61379&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61379&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61379&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61379&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61379&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61379&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61379&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61379&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61379&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61379&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61379&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61379&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61379&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61379&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61379&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61379&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61379&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61379&r=mysqlcfg
Bug #61257 [Opn]: '--enable-fpm' makes gmake fail building in FreeBSD on a Sheevaplug
Edit report at https://bugs.php.net/bug.php?id=61257&edit=1 ID: 61257 User updated by:jensrasmus at gmail dot com Reported by:jensrasmus at gmail dot com Summary:'--enable-fpm' makes gmake fail building in FreeBSD on a Sheevaplug Status: Open Type: Bug Package:Compile Failure Operating System: FreeBSD 8.2-STABLE armeb PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Hej! Thank you schnorte! By editing sapi/fpm/fpm/fpm_atomic.h manually the make compilation process completed successfully. I hope this change will be added to the next minor version of php 5.3 (i.e. 5.3.11) and 5.4. Though I do not think the patch works normally by using `patch -p0 < patchfile' or `patch -C < patchfile'; but thats probably just me not being used to patching files ... Previous Comments: [2012-03-12 18:52:36] schnorte at gmail dot com hej jensrasmus, i figured out a working patch with help of some really nice guys in a freebsd/arm chatroom. see if it works for you! [2012-03-12 00:14:06] schnorte at gmail dot com i can confirm this for sheevaplug with freebsd 9.0 and PHP 5.3.10_1 it seems that the generic solution in sapi/fpm/fpm/fpm_atomic.h for __ARM__: #define atomic_cmp_set(a,b,c) __sync_bool_compare_and_swap(a,b,c) is not working in freebsd? can anyone provide instead of some atomic operations assembler code for the arm(v5) architecture? [2012-03-02 23:57:38] jensrasmus at gmail dot com Description: I configured the php 5.4.0 source like this: ./configure --enable-fpm --enable-cgi --enable-fastcgi --prefix=/usr/local/php and then tried to compile with the gmake command. I expected it to complete compiling successfully so I could do a `gmake install'. What actually happened was a compile failure with this output at the end: ---ERROR MSG START--- In file included from /home/rasmus/php/php- 5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:15, from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21: /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). In file included from /home/rasmus/php/php- 5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:15, from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21: /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_atomic.h:146: error: expected ')' before '*' token In file included from /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm.c:21: /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:22: error: expected specifier-qualifier-list before 'atomic_t' /home/rasmus/php/php-5.4.0/sapi/fpm/fpm/fpm_scoreboard.h:51: error: expected specifier-qualifier-list before 'atomic_t' gmake: *** [sapi/fpm/fpm/fpm.lo] Error 1 ---ERROR MSG END--- Also, this happened on FreeBSD/arm on a Marvell Sheevaplug. If I remove `-- enable-fpm' from the configure command, make completes successfully; so this may be a FPM related problem. This is my complete `uname -a': FreeBSD frodo 8.2-STABLE FreeBSD 8.2-STABLE #7: Fri Feb 17 01:37:05 CET 2012 root@frodo:/usr/obj/usr/src/sys/FRODO arm -- Edit this bug report at https://bugs.php.net/bug.php?id=61257&edit=1
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: ram...@php.net
Reported by:ram...@php.net
Summary:file_get_contents() no longer returns false on 4xx
responses
Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: CentOS 6.2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having
the
same problem there (I've tried even with ignore_errors set to false).
Here are the PHP build notes for my Debian installation:
http://pastie.org/3588244
Previous Comments:
[2012-03-13 15:20:20] ram...@php.net
I'm still seeing the problem with ignore_errors set to false. See below for how
I'm setting ignore_errors. For full details on how my environment is set up,
you
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.
array(
'ignore_errors' => false
)
));
$response =
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false,
$context);
var_dump($http_response_header);
var_dump($response);
[2012-03-10 14:21:41] cataphr...@php.net
I can't reproduce this. Probably the default context has ignore_errors on.
Verify that it doesn't and try to pass a context that has ignore_errors set to
false.
[2012-03-09 22:41:50] s...@php.net
Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS
[2012-03-09 21:59:47] ram...@php.net
Description:
In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4,
file_get_contents() is returning the actual response body, rather than false.
Test script:
---
http://us3.php.net/manual/en/function.foobar.php');
var_dump($http_response_header);
var_dump($response);
Expected result:
With warnings turned on, this is what I get in PHP 5.3 and what I expect to see
in PHP 5.4:
PHP Warning:
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to
open stream: HTTP request failed! HTTP/1.0 404 Not Found
in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP 1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP 2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
[0]=>
string(22) "HTTP/1.0 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:57:32 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)
Actual result:
--
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:58:44 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
PHP: 404 Not Found
Bug #61378 [Com]: php -H doesn't work
Edit report at https://bugs.php.net/bug.php?id=61378&edit=1 ID: 61378 Comment by: rk at srsbiz dot pl Reported by:vr...@php.net Summary:php -H doesn't work Status: Open Type: Bug Package:CGI/CLI related Operating System: Irrelevant PHP Version:5.4.0 Block user comment: N Private report: N New Comment: This switch works, but does not hide arguments from running script (that would be rather pointless to pass arguments and switch to make them inaccessible) but from other users using same server (using 'ps aux' for example). Try for yourself: test.php: php test.php --mypass=adminadmin on second terminal: ps aux | grep adminadmin expected output: root 9627 0.0 0.0 3256 740 pts/2S+ 21:09 0:00 php test.php --mypass=adminadmin now try running with -H: php -H test.php --mypass=adminadmin and on second trerminal you should have no match, while greping only for php, you may find it, without any arguments: ps aux | grep php root 10012 0.8 0.8 44524 9156 pts/1S+ 21:10 0:00 php Previous Comments: [2012-03-13 19:45:21] vr...@php.net The following patch has been added/updated: Patch Name: hide-args.patch Revision: 1331667921 URL: https://bugs.php.net/patch-display.php?bug=61378&patch=hide-args.patch&revision=1331667921 [2012-03-13 19:44:54] vr...@php.net Description: `php -H` or `php --hide-args` should hide passed arguments from the running script but it does nothing. I've tried it on Windows and Linux. I think that this feature can be safely removed because it doesn't work for ages (at least since PHP 5.2.10 but probably longer) and I see only a little value in it. It is also the only undocumented option at http://php.net/features.commandline.options Test script: --- php -H argv.php a b argv.php: Expected result: Array ( ) Actual result: -- Array ( [0] => argv.php [1] => a [2] => b ) -- Edit this bug report at https://bugs.php.net/bug.php?id=61378&edit=1
Bug #61378 [PATCH]: php -H doesn't work
Edit report at https://bugs.php.net/bug.php?id=61378&edit=1 ID: 61378 Patch added by: vr...@php.net Reported by:vr...@php.net Summary:php -H doesn't work Status: Open Type: Bug Package:CGI/CLI related Operating System: Irrelevant PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: hide-args.patch Revision: 1331667921 URL: https://bugs.php.net/patch-display.php?bug=61378&patch=hide-args.patch&revision=1331667921 Previous Comments: [2012-03-13 19:44:54] vr...@php.net Description: `php -H` or `php --hide-args` should hide passed arguments from the running script but it does nothing. I've tried it on Windows and Linux. I think that this feature can be safely removed because it doesn't work for ages (at least since PHP 5.2.10 but probably longer) and I see only a little value in it. It is also the only undocumented option at http://php.net/features.commandline.options Test script: --- php -H argv.php a b argv.php: Expected result: Array ( ) Actual result: -- Array ( [0] => argv.php [1] => a [2] => b ) -- Edit this bug report at https://bugs.php.net/bug.php?id=61378&edit=1
[PHP-BUG] Bug #61378 [NEW]: php -H doesn't work
From: vrana Operating system: Irrelevant PHP version: 5.4.0 Package: CGI/CLI related Bug Type: Bug Bug description:php -H doesn't work Description: `php -H` or `php --hide-args` should hide passed arguments from the running script but it does nothing. I've tried it on Windows and Linux. I think that this feature can be safely removed because it doesn't work for ages (at least since PHP 5.2.10 but probably longer) and I see only a little value in it. It is also the only undocumented option at http://php.net/features.commandline.options Test script: --- php -H argv.php a b argv.php: Expected result: Array ( ) Actual result: -- Array ( [0] => argv.php [1] => a [2] => b ) -- Edit bug report at https://bugs.php.net/bug.php?id=61378&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61378&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61378&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61378&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61378&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61378&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61378&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61378&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61378&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61378&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61378&r=support Expected behavior: https://bugs.php.net/fix.php?id=61378&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61378&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61378&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61378&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61378&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61378&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61378&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61378&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61378&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61378&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61378&r=mysqlcfg
Bug #60976 [Com]: PHP crashes sometimes while parsing
Edit report at https://bugs.php.net/bug.php?id=60976&edit=1 ID: 60976 Comment by: pete dot walker at cap2 dot co dot uk Reported by:xrstf-misc at yahoo dot com Summary:PHP crashes sometimes while parsing Status: Open Type: Bug Package:Reproducible crash Operating System: Win7x64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I'm also suffering from this issue. I had phpunit randomly crashing. Traced the problem using xdebug - I'm using the Database YAML extension (PHPUnit_Extensions_Database_DataSet_YamlDataSet), and it uses the include statement to load the YAML files. The YAML file knocking everything over was exactly 8192 bytes long (and ended with whitespace, but not \n). Previous Comments: [2012-02-10 01:50:11] xrstf-misc at yahoo dot com This is actually a good hint by hanssen at aeteurope dot nl: I too had some cases where a generated cache file (containing "" without trailing newline. Inspection of lines 3181 and 3182 of Zend/zend_language_scanner.c reveals YYCURSOR being advanced one byte and a '\n' being expected, which fails here because it attempts to read memory beyond allocated memory. [2012-02-06 17:23:08] giunta dot gaetano at gmail dot com I also have php crashes - win7 64, apache 2.2.21 from apache lounge. No error messages left in either php or apache logs - just a "server reset connection" error from the browser. The code ran fine up to php 5.3.8 (did not test with 539). It involves executing a custom page within eZPublish, it is hard for me to trace it to a single php file / command and attach it here... [2012-02-05 15:19:32] xrstf-misc at yahoo dot com Here is the original file, wrapped in an 7z archive: http://www.xrstf.de/bug60976.7z (1KB) [2012-02-04 07:39:19] paj...@php.net Ah you already did. Which EOL do you use on your original script? Unix or windows ones? Maybe zip it and post a link to the zip file, so the contents won't be altered (lexer 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=60976 -- Edit this bug report at https://bugs.php.net/bug.php?id=60976&edit=1
Bug #61374 [Asn->Csd]: html_entity_decode tries to decode code points that don't exist in ISO-8859-1
Edit report at https://bugs.php.net/bug.php?id=61374&edit=1 ID: 61374 Updated by: cataphr...@php.net Reported by:cataphr...@php.net Summary:html_entity_decode tries to decode code points that don't exist in ISO-8859-1 -Status: Assigned +Status: Closed Type: Bug Package:*General Issues Operating System: Irrelevant PHP Version:5.4SVN-2012-03-13 (SVN) Assigned To:cataphract Block user comment: N Private report: N New Comment: Fixed in SVN. Previous Comments: [2012-03-13 18:08:20] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=324199 Log: - Fixed bug #61374: html_entity_decode tries to decode code points that don't exist in ISO-8859-1. [2012-03-13 15:13:38] cataphr...@php.net Description: html_entity_decode tries to decode code points that don't exist in ISO-8859-1. The result is that the codepoint(s) being written mod 256. Test script: --- https://bugs.php.net/bug.php?id=61374&edit=1
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795&edit=1
ID: 48795
Comment by: dan at cdchase dot com
Reported by:gwy...@php.net
Summary:Building intl 64-bit fails on OS X
Status: Verified
Type: Bug
Package:Compile Failure
Operating System: OS X 10.5 & 10.6; Linux
PHP Version:5.3 SVN; 5.4.0RC1
Block user comment: N
Private report: N
New Comment:
It would be helpful if the build system imported any already set CFLAGS. As
I've experienced this issue before, so I've set the appropriate CFLAGS in my
default environment. But, the automated install routine does not honor these. I
have to manually install for them to be honored.
Previous Comments:
[2011-11-14 16:54:00] weierophin...@php.net
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1
on linux 64-bit.
[2011-11-11 11:30:21] ahar...@php.net
tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.
Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
"multiarch" support. Both libcurl and libicu are the normal packaged
versions.
With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:
/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
Diffing the Makefile produced by --enable-intl alone with the
"--enable-intl --with-curl" combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):
@@ -75,9 +76,9 @@
CXXFLAGS_CLEAN = -g -O2
DEBUG_CFLAGS =
EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
ZEND_EXTRA_LIBS =
INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
LFLAGS =
LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
PEAR_INSTALLDIR = ${exec_prefix}/lib/php
PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
PHP_LIBS =
OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
PHP_SAPI = none
PHP_VERSION = 5.4.0RC1
PHP_VERSION_ID = 50400
Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.
I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed "properly"
(whatever form that takes -- it may even up being an upstream issue)?
[2011-11-06 19:11:09] luke at cywh dot com
Is there going to be a proper fix for this any time soon? I'm having a lot of
trouble getting 5.3.8 to compile on OS X 10.6.8.
[2011-07-01 16:23:27] harald dot lapp at gmail dot com
just setting the EXTRA_LIBS did not work for me, but stas tip made it work.
(PHP
5.3.6, Mac OS X 10.6.7), thanks!
[2010-06-17 19:43:39] henrik at bearwoods dot dk
I have tried the above "quick-fi
Bug #61376 [Com]: saveHTML only allows one option element to have the selected attribute.
Edit report at https://bugs.php.net/bug.php?id=61376&edit=1 ID: 61376 Comment by: jrbeaure at uvm dot edu Reported by:jrbeaure at uvm dot edu Summary:saveHTML only allows one option element to have the selected attribute. Status: Open Type: Bug Package:DOM XML related Operating System: Linux (Unknown Derivative) PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I forgot to mention in the description my work around. I use saveXML instead, which works. However, this also breaks my code because the CDATA node markup in script tags cause the scripts to break in browsers, regardless of whether it's the official standard. To get around this I used preg_replace to surround the markup with javascript /*comment*/ markup. Previous Comments: [2012-03-13 15:30:33] jrbeaure at uvm dot edu Description: I've been having a very hard time trying to use the DOMDocument class for this purpose, and it's taken me three days to figure out how to work around the bugs. When loading elements from different selects: If there is a presently selected option, I remove the selected attribute from the option using the DOMElement removeAttribute method. Then I use the DOMElement setAttribute method to set the attribute 'selected' to the value 'selected'. I do this for two different options that are children of two different select elements. -- Edit this bug report at https://bugs.php.net/bug.php?id=61376&edit=1
Bug #61371 [Fbk->Opn]: stream_context_create() causes memory leaks on use streams_socket_create
Edit report at https://bugs.php.net/bug.php?id=61371&edit=1
ID: 61371
User updated by:raiderz at gmail dot com
Reported by:raiderz at gmail dot com
Summary:stream_context_create() causes memory leaks on use
streams_socket_create
-Status: Feedback
+Status: Open
Type: Bug
Package:Streams related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I update to 5.3.11-dev from snaps, bug already have in this version.
New result:
memory: 317kb
memory: 338kb
memory: 359kb
memory: 380kb
memory: 400kb
Previous Comments:
[2012-03-13 14:32:22] cataphr...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2012-03-13 10:29:25] raiderz at gmail dot com
Description:
stream_context_create() causes memory leaks on use width stream_socket_client
Version PHP 5.3.6
Test script:
---
for($test=1;$test<=5;$test++) {
echo 'memory: '.round(memory_get_usage()/1024, 0)."kb\n";
for($i=0;$i<=100;$i++) {
$context = stream_context_create(array());
$stream = stream_socket_client('udp://0.0.0.0:80', $errno,
$errstr, 10, STREAM_CLIENT_CONNECT, $context);
fclose($stream);
unset($context);
unset($stream);
}
}
Expected result:
memory: 615kb
memory: 674kb
memory: 732kb
memory: 790kb
memory: 847kb
--
Edit this bug report at https://bugs.php.net/bug.php?id=61371&edit=1
[PHP-BUG] Bug #61376 [NEW]: saveHTML only allows one option element to have the selected attribute.
From: Operating system: Linux (Unknown Derivative) PHP version: 5.3.10 Package: DOM XML related Bug Type: Bug Bug description:saveHTML only allows one option element to have the selected attribute. Description: I've been having a very hard time trying to use the DOMDocument class for this purpose, and it's taken me three days to figure out how to work around the bugs. When loading elements from different selects: If there is a presently selected option, I remove the selected attribute from the option using the DOMElement removeAttribute method. Then I use the DOMElement setAttribute method to set the attribute 'selected' to the value 'selected'. I do this for two different options that are children of two different select elements. -- Edit bug report at https://bugs.php.net/bug.php?id=61376&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61376&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61376&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61376&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61376&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61376&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61376&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61376&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61376&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61376&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61376&r=support Expected behavior: https://bugs.php.net/fix.php?id=61376&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61376&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61376&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61376&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61376&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61376&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61376&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61376&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61376&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61376&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61376&r=mysqlcfg
Bug #61246 [Com]: Error when running PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=61246&edit=1 ID: 61246 Comment by: gonperes at gmail dot com Reported by:osmanungur at gmail dot com Summary:Error when running PHP-FPM Status: Open Type: Bug Package:FPM related Operating System: Mac Os X 10.7.3 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Greetings. I just downloaded latest dev version (5.4.1RC1-dev) and i'm still having this problem: Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): invalid pointer: 0x2aedda63c698 *** (...) and a bunch of lines after this (...) Everything seems to be working though. It's just this annoying error message. My setup: './configure' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www- data' '--with-curl' '--with-gd' '--with-jpeg-dir' '--with-freetype-dir' '-- enable-gd-native-ttf' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with- pear' '--enable-soap' '--with-imap' '--with-imap-ssl' '--with-kerberos' '-- disable-pdo' '--with-zlib' '--with-openssl' '--enable-zip' make make install pecl install apc Cheers! Previous Comments: [2012-03-12 15:34:22] Jared dot Williams1 at ntlworld dot com Problem seems fixed in r324146 [2012-03-10 14:01:34] Jared dot Williams1 at ntlworld dot com Actually r323587 is fine too it seems, but r323990 introduces the problem. [2012-03-10 13:49:06] Jared dot Williams1 at ntlworld dot com svn head (currently r324037) contains this problem. Reverted back to r316786 which doesn't. [2012-03-09 23:38:04] dancom96 at gmail dot com I copy pasted the wrong link in my last comment, but the latest SVN APC seems to be broken again. I compiled with SVN APC a couple days ago and it worked fine; but today I redownloaded it and recompiled, and I now have the same error once again. [2012-03-09 17:26:09] ras...@php.net okspam01 use APC from svn for now until we get a new APC release out. 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=61246 -- Edit this bug report at https://bugs.php.net/bug.php?id=61246&edit=1
Bug #61336 [Com]: file_get_contents() no longer returns false on 4xx responses
Edit report at https://bugs.php.net/bug.php?id=61336&edit=1
ID: 61336
Comment by: ram...@php.net
Reported by:ram...@php.net
Summary:file_get_contents() no longer returns false on 4xx
responses
Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: CentOS 6.2
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
I'm still seeing the problem with ignore_errors set to false. See below for how
I'm setting ignore_errors. For full details on how my environment is set up,
you
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.
array(
'ignore_errors' => false
)
));
$response =
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false,
$context);
var_dump($http_response_header);
var_dump($response);
Previous Comments:
[2012-03-10 14:21:41] cataphr...@php.net
I can't reproduce this. Probably the default context has ignore_errors on.
Verify that it doesn't and try to pass a context that has ignore_errors set to
false.
[2012-03-09 22:41:50] s...@php.net
Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS
[2012-03-09 21:59:47] ram...@php.net
Description:
In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4,
file_get_contents() is returning the actual response body, rather than false.
Test script:
---
http://us3.php.net/manual/en/function.foobar.php');
var_dump($http_response_header);
var_dump($response);
Expected result:
With warnings turned on, this is what I get in PHP 5.3 and what I expect to see
in PHP 5.4:
PHP Warning:
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to
open stream: HTTP request failed! HTTP/1.0 404 Not Found
in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP 1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP 2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
[0]=>
string(22) "HTTP/1.0 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:57:32 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)
Actual result:
--
array(11) {
[0]=>
string(22) "HTTP/1.1 404 Not Found"
[1]=>
string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(23) "X-Powered-By: PHP/5.3.2"
[4]=>
string(20) "Content-language: en"
[5]=>
string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT;
path=/; domain=.php.net"
[6]=>
string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012
21:58:44 GMT; path=/; domain=.php.net"
[7]=>
string(21) "Status: 404 Not Found"
[8]=>
string(20) "Content-Length: 4219"
[9]=>
string(17) "Connection: close"
[10]=>
string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">
PHP: 404 Not Found
[PHP-BUG] Bug #61374 [NEW]: html_entity_decode tries to decode code points that don't exist in ISO-8859-1
From: cataphract Operating system: Irrelevant PHP version: 5.4SVN-2012-03-13 (SVN) Package: *General Issues Bug Type: Bug Bug description:html_entity_decode tries to decode code points that don't exist in ISO-8859-1 Description: html_entity_decode tries to decode code points that don't exist in ISO-8859-1. The result is that the codepoint(s) being written mod 256. Test script: --- https://bugs.php.net/bug.php?id=61374&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61374&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61374&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61374&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61374&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61374&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61374&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61374&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61374&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61374&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61374&r=support Expected behavior: https://bugs.php.net/fix.php?id=61374&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61374&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61374&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61374&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61374&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61374&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61374&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61374&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61374&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61374&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61374&r=mysqlcfg
Req #60075 [Com]: using -t /myPath does not add /myPath to include_path
Edit report at https://bugs.php.net/bug.php?id=60075&edit=1
ID: 60075
Comment by: ly...@php.net
Reported by:paul dot a dot norman at gmail dot com
Summary:using -t /myPath does not add /myPath to
include_path
Status: Assigned
Type: Feature/Change Request
Package:Built-in web server
Operating System: Win32
PHP Version:5.4.0beta1
Assigned To:moriyoshi
Block user comment: N
Private report: N
New Comment:
You don't need a new flag.
php -B ini_set('include_path', get_include_path() . PATH_SEPARATOR . '/myPath')
NOTE:
Never used -B, so maybe you need "" around it or whatever, but you get the
point.
Previous Comments:
[2012-03-08 05:09:14] reeze dot xia at gmail dot com
Hi, Stuart
I think add doc-root to include_path may impact the behavior of your
application, because this changes the include path of your application too.
maybe some application didn't add docroot to it's include_path , but the server
add it. (include require autoload etc.).
if you just want to set router script easily, I don't think it deserve the
change. And this behavior different with the way we use cli tools:
ie:
$ ls -l file.php
just print the information of $PWD's file.php but not some other folder's
file.php. This is confusing
If we want to add include path maybe a new option like -I /new/include/path
maybe useful.
so -1 for me ;-)
Thanks.
reeze
[2012-03-04 18:04:05] stuart at 3ft9 dot com
This is my first patch so I may have missed something. This patch simply
prepends
the document root to include_path for each request.
[2011-10-17 07:59:21] paul dot a dot norman at gmail dot com
Description:
If the php internal server is launched using php -S localhost:8001 -t /myPath
server_process.php
and server_process.php is in /myPath the following would result
Warning: Unknown: failed to open stream: No such file or directory in Unknown
on
line 0
Fatal error: Unknown: Failed opening required 'server_process.php'
(include_path='.;C:\php\pear') in Unknown on line 0
Obviously using: ... -t /myPath /myPath/server_process.php
works as expected,
but it would seem intuitive that when using:
php -S localhost:8001 -t something
that "something" would be automatically added to the include_path ?
P.S. the php internal server is a brilliant addition, facilitates making
virtual
desktop applications in the browser a cinch! Allows the leveraging of browser
technology jQuery and all the rest with php on the client -- very powerful!!!
Add in http://gluescript.sourceforge.net/ http://gtk.php.net/ or simillar for
local wxWdiget dialogues called as necessary from php
http://php.net/manual/en/function.system.php and an almost complete powerful
solution is available.
Paul
--
Edit this bug report at https://bugs.php.net/bug.php?id=60075&edit=1
Req #16422 [Com]: utf8_encode/utf8_decode requires the XML extension
Edit report at https://bugs.php.net/bug.php?id=16422&edit=1 ID: 16422 Comment by: dsd31g at gmail dot com Reported by:marten at ditt dot as Summary:utf8_encode/utf8_decode requires the XML extension Status: No Feedback Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:4.1.2 Block user comment: N Private report: N New Comment: i have the same problem. i don't use xml. xml is a very bad format. i don't want compile php with xml support but i need utf8_encode and utf8_decode. Previous Comments: [2002-07-15 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a month, 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". [2002-04-04 07:03:10] sni...@php.net Why? Don't disable xml.. [2002-04-04 04:34:51] marten at ditt dot as Currently, utf8_encode() and utf8_decode() are part of the XML extension and will not be available if PHP is configured with --disable-xml Would it be possible to make these functions "native" PHP functions, so that they always will be available? -- Edit this bug report at https://bugs.php.net/bug.php?id=16422&edit=1
Bug #61371 [Opn->Fbk]: stream_context_create() causes memory leaks on use streams_socket_create
Edit report at https://bugs.php.net/bug.php?id=61371&edit=1
ID: 61371
Updated by: cataphr...@php.net
Reported by:raiderz at gmail dot com
Summary:stream_context_create() causes memory leaks on use
streams_socket_create
-Status: Open
+Status: Feedback
Type: Bug
Package:Streams related
Operating System: Linux
PHP Version:Irrelevant
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/
Previous Comments:
[2012-03-13 10:29:25] raiderz at gmail dot com
Description:
stream_context_create() causes memory leaks on use width stream_socket_client
Version PHP 5.3.6
Test script:
---
for($test=1;$test<=5;$test++) {
echo 'memory: '.round(memory_get_usage()/1024, 0)."kb\n";
for($i=0;$i<=100;$i++) {
$context = stream_context_create(array());
$stream = stream_socket_client('udp://0.0.0.0:80', $errno,
$errstr, 10, STREAM_CLIENT_CONNECT, $context);
fclose($stream);
unset($context);
unset($stream);
}
}
Expected result:
memory: 615kb
memory: 674kb
memory: 732kb
memory: 790kb
memory: 847kb
--
Edit this bug report at https://bugs.php.net/bug.php?id=61371&edit=1
Bug #61335 [Com]: Access to array node returns wrong truth value
Edit report at https://bugs.php.net/bug.php?id=61335&edit=1
ID: 61335
Comment by: cschneid at cschneid dot com
Reported by:mueller at relog dot ch
Summary:Access to array node returns wrong truth value
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
It seems commit 311171 broke it:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/simplexml/simplexml.c?r1=311171&r2=311170&pathrev=311171
Previous Comments:
[2012-03-13 13:19:01] mueller at relog dot ch
The other bug is said to have been fixed in svn, however my bug still happens
in
the current version from svn.
[2012-03-10 00:00:29] me at ktamura dot com
I think this bug is related to https://bugs.php.net/bug.php?id=51615
[2012-03-09 18:00:28] mueller at relog dot ch
I forgot: Omitting the [0] array access will also fix the problem.
[2012-03-09 17:57:50] mueller at relog dot ch
Description:
When accessing a simplexml node as array, I always get an empty simplexml
object.
If I cast the node to string, the behaviour is correct.
If the parent node contains nothing but the child node (not even a newline)
then
the behaviour is also correct.
Under php 5.3, the behaviour is correct.
Test script:
---
$rec1 = simplexml_load_string("aa\n");
$rec2 = simplexml_load_string("aa");
if ($rec1->bar[0]) echo "NONEMPTY1\n"; # not reached, bug
if ($rec1->bar[0] . "") echo "NONEMPTY2\n"; # correct
if ($rec2->bar[0]) echo "NONEMPTY3\n"; # correct
Expected result:
NONEMPTY1
NONEMPTY2
NONEMPTY3
Actual result:
--
NONEMPTY2
NONEMPTY3
--
Edit this bug report at https://bugs.php.net/bug.php?id=61335&edit=1
Bug #61143 [Com]: XML Parser segfaults on large xml
Edit report at https://bugs.php.net/bug.php?id=61143&edit=1
ID: 61143
Comment by: seth dot mos at dds dot nl
Reported by:seth dot mos at dds dot nl
Summary:XML Parser segfaults on large xml
Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: FreeBSD 8.3
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I managed to get a core file and the output from truss.
This is from a PHP with Suhosin, without Suhosin PHP does not core dump
http://iserv.nl/files/pfsense/phpcore/
Not sure if that is enough.
Previous Comments:
[2012-02-27 19:16:15] seth dot mos at dds dot nl
Just confirmed that disabling the Suhosin extension in our PHP 5.3.10 build
succesfully resolves the crash.
We will take this up with the Suhosin maintainers.
Kind regards,
[2012-02-20 17:50:08] ras...@php.net
I tried to reproduce this crash with the provided files on both Linux and
FreeBSD
and was unable to. We'll need more information. Could you get a backtrace for
us?
And second, could you try it without Suhosin enabled?
[2012-02-20 13:11:28] seth dot mos at dds dot nl
Description:
Previously we used PHP 5.2.17 in pfSense 2.0 before we upgraded our build
process to the current 5.3.10.
We use the suplied xml to PHP array function in pfSense to convert RRD files
and add new fields to RRD files.
Here is the PHP version that we use on pfSense.
[2.1-DEVELOPMENT][root@pfsense.localdomain]/root(1): php -v
PHP 5.3.10 with Suhosin-Patch (cgi-fcgi) (built: Feb 17 2012 14:05:19)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
$xml = file_get_contents("wan-traffic.rrd.old.xml");
$array = xml2array($xml, 1, "tag");
/* this ^^ causes a segfault */
Please see the complete code below and a test file to work on.
Test script:
---
PHP code that triggers our crash, please download the entire code and XML file
from:
http://iserv.nl/files/pfsense/php/wan-traffic.rrd.old.xml
http://iserv.nl/files/pfsense/php/testscript.txt
Expected result:
Return a array of the XML data.
Actual result:
--
PHP core dumps with a signal 11.
http://iserv.nl/files/pfsense/php/php%20core%20dump%205.3.10%20freebsd%208.3.png
--
Edit this bug report at https://bugs.php.net/bug.php?id=61143&edit=1
Bug #61335 [Opn]: Access to array node returns wrong truth value
Edit report at https://bugs.php.net/bug.php?id=61335&edit=1
ID: 61335
User updated by:mueller at relog dot ch
Reported by:mueller at relog dot ch
Summary:Access to array node returns wrong truth value
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: Linux
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The other bug is said to have been fixed in svn, however my bug still happens
in
the current version from svn.
Previous Comments:
[2012-03-10 00:00:29] me at ktamura dot com
I think this bug is related to https://bugs.php.net/bug.php?id=51615
[2012-03-09 18:00:28] mueller at relog dot ch
I forgot: Omitting the [0] array access will also fix the problem.
[2012-03-09 17:57:50] mueller at relog dot ch
Description:
When accessing a simplexml node as array, I always get an empty simplexml
object.
If I cast the node to string, the behaviour is correct.
If the parent node contains nothing but the child node (not even a newline)
then
the behaviour is also correct.
Under php 5.3, the behaviour is correct.
Test script:
---
$rec1 = simplexml_load_string("aa\n");
$rec2 = simplexml_load_string("aa");
if ($rec1->bar[0]) echo "NONEMPTY1\n"; # not reached, bug
if ($rec1->bar[0] . "") echo "NONEMPTY2\n"; # correct
if ($rec2->bar[0]) echo "NONEMPTY3\n"; # correct
Expected result:
NONEMPTY1
NONEMPTY2
NONEMPTY3
Actual result:
--
NONEMPTY2
NONEMPTY3
--
Edit this bug report at https://bugs.php.net/bug.php?id=61335&edit=1
Bug #49139 [Com]: proc_open requires double quotes
Edit report at https://bugs.php.net/bug.php?id=49139&edit=1
ID: 49139
Comment by: david dot gausmann at measx dot com
Reported by:david dot gausmann at measx dot com
Summary:proc_open requires double quotes
Status: Feedback
Type: Bug
Package:Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version:5.3.0
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
This bug is still present in PHP 5.4.
According to my previous example I've replaced the command line by the php
interpreter and the reference to a script:
$cmd = '"d:\php-5.4.0\php.exe" "C:\xampp\htdocs\Neuer Ordner\script2.php"';
If I execute your script with the command line above I will get the following
output:
-
D:\php-5.4.0>php -f C:\xampp\htdocs\testx.php
string(0) ""
string(0) ""
string(93) "Die Syntax für den Dateinamen, Verzeichnisnamen oder die
Datenträger
bezeichnung ist falsch.
"
exec:
Lorem ipsum
Array
(
[0] => Lorem ipsum
)
-
If I move the file "script2.php" to an other location (without any spaces in
it's path) then it works if I remove the double quotes from the parameter.
So the error only occurs if the parameters use double quotes, too.
In your example no parameters were used, so the error doesn't occured.
I've tested this with PHP 5.4 on Windows XP SP3.
Previous Comments:
[2011-02-09 12:22:15] paj...@php.net
@xandrani at googlemail dot com
'"c:\program files\doxygen\bin\doxygen.exe" "C:\fred\doxyfile"'
works fine with proc_open.
For the initial comment and other:
array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')
);
$resource = proc_open($cmd, $des, $pipes, null, $_ENV);
var_dump(stream_get_contents($pipes[0]));
var_dump(stream_get_contents($pipes[1]));
var_dump(stream_get_contents($pipes[2]));
echo PHP_EOL;
echo "exec: " . PHP_EOL;
echo exec($cmd, $ret);
echo PHP_EOL;
print_r($ret);
echo PHP_EOL;
gives me:
string(0) ""
string(441) "Usage: wcutil [-s] [-d] [-x] [filename(*)]
-s(imple) Do not display CSV headers or average.
-x(ml) Xml output.
-d(rophighlow) Drop highest and lowest path runs.
Column details:
file - output filename
tps- transactions per second
kcpt - kilocycles per transaction (aka 'path')
bpt- bytes per transaction
cpu- percent CPU utilization
err- count of any errors
"
string(0) ""
exec:
Array
(
[0] => Usage: wcutil [-s] [-d] [-x] [filename(*)]
[1] => -s(imple) Do not display CSV headers or average.
[2] => -x(ml) Xml output.
[3] => -d(rophighlow) Drop highest and lowest path runs.
[4] =>
[5] => Column details:
[6] => file - output filename
[7] => tps- transactions per second
[8] => kcpt - kilocycles per transaction (aka 'path')
[9] => bpt- bytes per transaction
[10] => cpu- percent CPU utilization
[11] => err- count of any errors
[12] =>
)
which is correct.
Using 5.3.5 and 5.3-svn or trunk, on Windows 7/2003/2008.
Please try again and let me know if it still fails, using this exact sample
(can
be other command), or repost an example to reproduce it. I will also need to
know which windows version you use.
[2011-01-26 16:27:21] xc at ez dot no
Can someone speed up the fix? We have issue in our project based on this bug.
I assume second call in the example should work..
Related issue: https://issues.apache.org/jira/browse/ZETACOMP-48
Thanks.
[2010-04-23 08:46:52] David dot Gausmann at measx dot com
This is the same problem as mine:
$Command = '""c:\program files\doxygen\bin\doxygen.exe" "C:\fred\doxyfile""';
$DescriptorSpecification = array
(
0 => array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')
);
$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null, $_ENV);
Works fine (because it has the nasty double quotes around everything).
[2010-04-23 02:22:47] xandrani at googlemail dot com
The double backward slashes didn't show correctly... but they are in my code.
[2010-04-23 02:20:33] xandrani at googlemail dot com
Something similar fails for me... but even worse!
$Command = '"c:\program files\doxygen\bin\doxygen.exe" "C:\fred\doxyfile"'
$DescriptorSpecification = array
(
0 => array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')
);
$Resource = proc_open($Command, $DescriptorSpecification, $Pipes, null, $_
[PHP-BUG] Bug #61371 [NEW]: stream_context_create() causes memory leaks on use streams_socket_create
From:
Operating system: Linux
PHP version: Irrelevant
Package: Streams related
Bug Type: Bug
Bug description:stream_context_create() causes memory leaks on use
streams_socket_create
Description:
stream_context_create() causes memory leaks on use width
stream_socket_client
Version PHP 5.3.6
Test script:
---
for($test=1;$test<=5;$test++) {
echo 'memory: '.round(memory_get_usage()/1024, 0)."kb\n";
for($i=0;$i<=100;$i++) {
$context = stream_context_create(array());
$stream = stream_socket_client('udp://0.0.0.0:80', $errno,
$errstr, 10,
STREAM_CLIENT_CONNECT, $context);
fclose($stream);
unset($context);
unset($stream);
}
}
Expected result:
memory: 615kb
memory: 674kb
memory: 732kb
memory: 790kb
memory: 847kb
--
Edit bug report at https://bugs.php.net/bug.php?id=61371&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61371&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61371&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61371&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61371&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61371&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61371&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61371&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61371&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61371&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61371&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61371&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61371&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61371&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61371&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61371&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61371&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61371&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61371&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61371&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61371&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61371&r=mysqlcfg
[PHP-BUG] Bug #61370 [NEW]: Segmentation fault
From: Operating system: CentOS 5.8 64bits PHP version: 5.4.0 Package: FPM related Bug Type: Bug Bug description:Segmentation fault Description: Starting php-fpm as service generates a segfault. Backtrace: http://pastie.org/3584157 -- Edit bug report at https://bugs.php.net/bug.php?id=61370&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61370&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61370&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61370&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61370&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61370&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61370&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61370&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61370&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61370&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61370&r=support Expected behavior: https://bugs.php.net/fix.php?id=61370&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61370&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61370&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61370&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61370&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61370&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61370&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61370&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61370&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61370&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61370&r=mysqlcfg
Bug #61369 [Opn]: shm_put_var problem
Edit report at https://bugs.php.net/bug.php?id=61369&edit=1
ID: 61369
User updated by:llongo at sata-hts dot com
Reported by:llongo at sata-hts dot com
Summary:shm_put_var problem
Status: Open
Type: Bug
Package:Semaphore related
Operating System: CentOS release 6.2 (Final)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I've seen the bug with php version 5.3.3 that comes with Centos 6.2 (php-5.3.3-
3.el6_2.6.x86_64). With the same version of php in Centos 5.7 (php53-5.3.3-
1.el5_7.6) the test script works in the right way.
Previous Comments:
[2012-03-13 08:56:37] llongo at sata-hts dot com
Description:
There is a problem with shm_put_var: when you call shm_put_var with a "long"
string as value (100 chars at least) in a shared memory area with some
variables
already created, after updating the other variables with successive calls to
shm_put_var, this variables become non-existent and you cannot get their values
with shm_get_var.
Test script:
---
after this put var, var 2 and 3 disappear... bug?
echo "unable to put var 2 with ".$test1."\n";
}
if (false === ($var = shm_get_var ($res,2))) { // get var 2
echo "Error reading variable 2, bug!\n";
var_dump($var);
} else {
echo "variable 2: ".$var."\n";
}
shm_remove($res); // remove shared memory
shm_detach($res);
exit;
?>
Expected result:
variable 2: different short string
Actual result:
--
Error reading variable 2, bug!
bool(false)
And php warning:
PHP Warning: shm_get_var(): variable key 2 doesn't exist in
/root/test_bug_shm.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=61369&edit=1
[PHP-BUG] Bug #61369 [NEW]: shm_put_var problem
From:
Operating system: CentOS release 6.2 (Final)
PHP version: Irrelevant
Package: Semaphore related
Bug Type: Bug
Bug description:shm_put_var problem
Description:
There is a problem with shm_put_var: when you call shm_put_var with a
"long"
string as value (100 chars at least) in a shared memory area with some
variables
already created, after updating the other variables with successive calls
to
shm_put_var, this variables become non-existent and you cannot get their
values
with shm_get_var.
Test script:
---
after
this put var, var 2 and 3 disappear... bug?
echo "unable to put var 2 with ".$test1."\n";
}
if (false === ($var = shm_get_var ($res,2))) { // get var 2
echo "Error reading variable 2, bug!\n";
var_dump($var);
} else {
echo "variable 2: ".$var."\n";
}
shm_remove($res); // remove shared memory
shm_detach($res);
exit;
?>
Expected result:
variable 2: different short string
Actual result:
--
Error reading variable 2, bug!
bool(false)
And php warning:
PHP Warning: shm_get_var(): variable key 2 doesn't exist in
/root/test_bug_shm.php on line 19
--
Edit bug report at https://bugs.php.net/bug.php?id=61369&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61369&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61369&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61369&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61369&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61369&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61369&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61369&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61369&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61369&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61369&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61369&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61369&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61369&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61369&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61369&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61369&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61369&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61369&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61369&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61369&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61369&r=mysqlcfg
Req #60738 [Com]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1
ID: 60738
Comment by: kevin dot swinton at gmail dot com
Reported by:four dot zerooneunauthorized at gmail dot com
Summary:Allow 'set_error_handler' to handle NULL
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelivant
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
In the first instance, nothing in here relates to a bug, rather both are
feature requests.
The first request is for set_error_handler() to function in an identical way to
set_exception_handler() when called with a single NULL parameter. In the
interests of a more consistent API this would seem sensible.
The second request is for set_exception_handler() (and by extension
set_error_handler()) to behave in a different way when called with a single
NULL parameter.
Given there is no compelling argument, and that such a change could technically
break BC, and that the request in itself doesn't appear to achieve anything
useful, the suggestion would be that the first request could be implemented
whilst the second request has no case.
As a result, I have attached a patch to implement only the first request.
Previous Comments:
[2012-01-13 02:22:55] four dot zerooneunauthorized at gmail dot com
Description:
Can the 'set_error_handler' function be made to accept NULL as the parameter in
such a way as to reset this feature to the default state of -no- handler being
set? This would duplicate the behavior of the 'set_exception_handler' function.
Note: this change should not interfere with the 'restore_error_handler'
function.
And as for the 'set_exception_handler' function - if NULL is given as a
parameter, can the return value of 'set_exception_handler' be set to the
details of the previously set exception handler function (string or array)
instead of always '(bool) true' as it now does?
Test script:
---
function testhandler1($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('1: ' . print_r(func_get_args(), true));
die();
}
function testhandler2($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('2: ' . print_r(func_get_args(), true));
die();
}
var_dump(set_error_handler('testhandler1'));
var_dump(set_error_handler('testhandler2'));
var_dump(set_error_handler(null));
Expected result:
NULL
string(12) "testhandler1"
string(12) "testhandler2"
Actual result:
--
On line 'var_dump(set_error_handler(null));', a 'set_error_handler() expects
the argument () to be a valid callback' error is generated and handled by
function "testhandler2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
[PHP-BUG] Bug #61368 [NEW]: Upstream tarball includes cruft (*.orig and autom4te.cache)
From: ondrej Operating system: Any PHP version: 5.4.0 Package: *General Issues Bug Type: Bug Bug description:Upstream tarball includes cruft (*.orig and autom4te.cache) Description: On Mon, Mar 12, 2012 at 23:32, Stas Malyshev wrote: > On Mon, Mar 12, 2012 at 23:11, Christopher Jones wrote: > > The autom4te.cache and *.orig files originally mentioned are included in > > php.net's php-5.4.0.tar.bz2 > > I.e. this is a valid issue. > > Definitely seems to be a bug in the makedist script, since these files are > not in the SVN but appear when packaging. > > > OndÅej, please log a bug. Test script: --- ondrej@kiMac:/tmp$ md5 ~/Downloads/php-5.4.0.tar.gz MD5 (/Users/ondrej/Downloads/php-5.4.0.tar.gz) = 46b72e274c6ea7e775245ffdb81c9ce5 ondrej@kiMac:/tmp$ tar -tzvf ~/Downloads/php-5.4.0.tar.gz | grep .orig -rw-r--r-- 0 smalyshev staff 30417 29 úno 08:37 php-5.4.0/ext/standard/url_scanner_ex.c.orig -rw-r--r-- 0 smalyshev staff 27289 29 úno 08:37 php-5.4.0/ext/standard/var_unserializer.c.orig -rw-r--r-- 0 smalyshev staff 19670 29 úno 08:37 php-5.4.0/ext/pdo/pdo_sql_parser.c.orig -rw-r--r-- 0 smalyshev staff 518939 29 úno 08:37 php-5.4.0/ext/date/lib/parse_date.c.orig ondrej@kiMac:/tmp$ tar -tzvf ~/Downloads/php-5.4.0.tar.gz | grep autom4te drwxr-xr-x 0 smalyshev staff 0 29 úno 08:37 php-5.4.0/autom4te.cache/ -rw-r--r-- 0 smalyshev staff 3012815 29 úno 08:37 php-5.4.0/autom4te.cache/output.0 -rw-r--r-- 0 smalyshev staff 2855 29 úno 08:37 php-5.4.0/autom4te.cache/requests -rw-r--r-- 0 smalyshev staff 387029 29 úno 08:37 php-5.4.0/autom4te.cache/traces.0 Expected result: Neither .orig nor autom4te.cache/ directory in distribution tarball. -- Edit bug report at https://bugs.php.net/bug.php?id=61368&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61368&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61368&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61368&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61368&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61368&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61368&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61368&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61368&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61368&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61368&r=support Expected behavior: https://bugs.php.net/fix.php?id=61368&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61368&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61368&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61368&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61368&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61368&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61368&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61368&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61368&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61368&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61368&r=mysqlcfg
