[PHP-BUG] Bug #63404 [NEW]: Authenticated Smtp mail sending error

2012-10-31 Thread sreejayam2000 at gmail dot com 
From: sreejayam2000 at gmail dot com
Operating system: windows
PHP version:  5.3.18
Package:  Mail related
Bug Type: Bug
Bug description:Authenticated Smtp mail sending error

Description:

---
>From manual page: http://www.php.net/ref.mail
---


Expected result:

I want to send  a autheticated smtp mail.
 
SMTP Server : mail.authsmtp.com
  SMTP Ports  : 2525

I set these in php.ini.

mail() is used for send the mail.

I am getting warning message now.

SMTP server response: 513 5.0.0 Your email system must authenticate before
sending 
mail


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

[PHP-BUG] Bug #63405 [NEW]: Segfault with traits and namespaces and as operator

2012-10-31 Thread mbret...@php.net 
From: mbretter
Operating system: Ubuntu 12.04 32bit
PHP version:  5.4.8
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Segfault with traits and namespaces and as operator

Description:

It looks like that this segfault occurs on every second request, when using
namespaces + traits + autloader + 'as' operator.

Without 'as' op it works.


Test script:
---
_setQueryParam($query, $p, $op, $v);
}
}   

...
}

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
zend_do_bind_traits (ce=0xb6c0873c) at
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
4029/build/buildd/php5-5.4.8/Zend/zend_compile.c: No such file or
directory.
(gdb) bt
#0  zend_do_bind_traits (ce=0xb6c0873c) at
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
#1  0xb6785bab in ZEND_BIND_TRAITS_SPEC_HANDLER (execute_data=0xb75ab04c)
at /build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:1027
#2  0xb67bc975 in execute (op_array=0xb67442a6) at
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#3  0xb67442a6 in zend_call_function (fci=0x0, fci_cache=0x0) at
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:958
#4  0xb676abd4 in zend_call_method (object_pp=, obj_ce=, 
fn_proxy=, function_name=, 
function_name_len=, retval_ptr_ptr=, 
param_count=, arg1=, 
arg2=) at /build/buildd/php5-5.4.8/Zend/zend_interfaces.c:97
#5  0xb662772a in zif_spl_autoload_call (ht=0, return_value=0x1,
return_value_ptr=0x80225b58, this_ptr=0x0, return_value_used=-2145232000)
at /build/buildd/php5-5.4.8/ext/spl/php_spl.c:436
#6  0xb6744379 in zend_call_function (fci=0x5283354c, fci_cache=0xbfffcd0b)
at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:980
#7  0xb6744b8d in zend_lookup_class_ex (name=0x802278a8
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45,
key=0x0, use_autoload=1, ce=0xbfffcda0) at
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1127
#8  0xb6744d4b in zend_lookup_class (name=0x802278a8
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45,
ce=0xbfffcda0) at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1152
#9  0xb6764d21 in zif_class_exists (ht=2, return_value=0x80225924,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/build/buildd/php5-5.4.8/Zend/zend_builtin_functions.c:1233
#10 0xb6800dfa in zend_do_fcall_common_helper_SPEC
(execute_data=0xb75aa9f0) at
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:642
#11 0xb67bc975 in execute (op_array=0xb6753729) at
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#12 0xb6753729 in zend_execute_scripts (type=0, retval=0xb164,
file_count=0) at /build/buildd/php5-5.4.8/Zend/zend.c:1309
#13 0xb66ecdae in php_execute_script (primary_file=0xb164) at
/build/buildd/php5-5.4.8/main/main.c:2482
#14 0xb68036c0 in php_handler (r=0xb2c61888) at
/build/buildd/php5-5.4.8/sapi/apache2handler/sapi_apache2.c:682


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

Bug #62738 [Com]: max_input_vars and stream upload

2012-10-31 Thread david at davidsteinsland dot net 
Edit report at https://bugs.php.net/bug.php?id=62738&edit=1

 ID: 62738
 Comment by: david at davidsteinsland dot net
 Reported by:david at davidsteinsland dot net
 Summary:max_input_vars and stream upload
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   CentOS 6.2
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

The solution was posted recently on Stackoverflow:
http://stackoverflow.com/a/13089138/414414

The directive "enable_post_data_reading" was set to "Off", to prevent PHP from 
parsing the input data and populating $_POST and $_FILES. The max_input_vars 
does not need to be incremented.


Previous Comments:

[2012-08-03 12:07:12] david at davidsteinsland dot net

Description:

When I try to upload files from Java through PHP, the logs give me messages 
about:
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.

Test script:
---
// read file contents from stream, and copy into a temporary file in order to 
get filesize
$putdata = fopen("php://input", "r");
$tmp = tmpfile();
$filesize = stream_copy_to_stream ($putdata, $tmp);
fclose ($putdata);

// move file to correct position
$target = fopen($filepath, "w");
fseek($tmp, 0, SEEK_SET);
stream_copy_to_stream($tmp, $target);
fclose($target);
fclose ($tmp);

Actual result:
--
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.






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

Bug #62738 [Opn->Csd]: max_input_vars and stream upload

2012-10-31 Thread david at davidsteinsland dot net 
Edit report at https://bugs.php.net/bug.php?id=62738&edit=1

 ID: 62738
 User updated by:david at davidsteinsland dot net
 Reported by:david at davidsteinsland dot net
 Summary:max_input_vars and stream upload
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   CentOS 6.2
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

The solution was posted recently on Stackoverflow:
http://stackoverflow.com/a/13089138/414414

The directive "enable_post_data_reading" was set to "Off", to prevent PHP from 
parsing the input data and populating $_POST and $_FILES. The max_input_vars 
does not need to be incremented.


Previous Comments:

[2012-10-31 10:06:15] david at davidsteinsland dot net

The solution was posted recently on Stackoverflow:
http://stackoverflow.com/a/13089138/414414

The directive "enable_post_data_reading" was set to "Off", to prevent PHP from 
parsing the input data and populating $_POST and $_FILES. The max_input_vars 
does not need to be incremented.


[2012-08-03 12:07:12] david at davidsteinsland dot net

Description:

When I try to upload files from Java through PHP, the logs give me messages 
about:
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.

Test script:
---
// read file contents from stream, and copy into a temporary file in order to 
get filesize
$putdata = fopen("php://input", "r");
$tmp = tmpfile();
$filesize = stream_copy_to_stream ($putdata, $tmp);
fclose ($putdata);

// move file to correct position
$target = fopen($filepath, "w");
fseek($tmp, 0, SEEK_SET);
stream_copy_to_stream($tmp, $target);
fclose($target);
fclose ($tmp);

Actual result:
--
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.






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

Req #51665 [Com]: MariaDB support

2012-10-31 Thread albertestillore at yahoo dot com 
Edit report at https://bugs.php.net/bug.php?id=51665&edit=1

 ID: 51665
 Comment by: albertestillore at yahoo dot com
 Reported by:koteskie at gmail dot com
 Summary:MariaDB support
 Status: Not a bug
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   all
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

Is their any updates on this threads? I'm having problem when using mariaDB php 
and wordpress. In cli mariadb is running good no problem in imports and export 
but when I install wordpress it show: "Your PHP installation appears to be 
missing the MySQL extension which is required by WordPress."

hope anyone has an idea on this to help me out


Previous Comments:

[2010-04-26 12:27:56] koteskie at gmail dot com

Perhaps i had to ask before how it would be possible to use MariaDB using 
libmysql or mysqlnd as I didn't find anything in the docs about the subject.
Could you perhaps elaborate on the howto?


[2010-04-26 12:24:50] johan...@php.net

The MariaDB developers didn't change the client protocol in any way. MySQL 
Connectors need no changes.


[2010-04-26 12:23:25] paj...@php.net

What else do you need to connect to MariaDB? MariaDB is 100% compatible with 
standard mysql clients, uncluding libmysql or mysqlnd.


[2010-04-26 12:19:50] koteskie at gmail dot com

Description:

I would really like to see support for MariaDB in PHP's PDO stack. Are there 
any plans for supporting that ? MariaDB is recently released in it
's first stable version which is fully mysql backwards compatible and has some 
very interesting new features and support for other storage engines like PBXT.







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

Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class

2012-10-31 Thread denis at slik dot eu 
Edit report at https://bugs.php.net/bug.php?id=52412&edit=1

 ID: 52412
 Comment by: denis at slik dot eu
 Reported by:madboyka at yahoo dot com
 Summary:__autoload fails to throw exception when calling a
 static method on the class
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Can't reproduce this anymore on 5.4.3.
Good riddance.


Previous Comments:

[2012-06-10 17:54:19] rahuijts at tiscali dot nl

Please
- explain (and let the documentation show) why it is not possible to throw an 
exception in the __autoload function if a static call is made on a non-existing 
class, when it is possible to do so if a non-existing class is instantiated,
- or reopen this bug report to acknowledge that it should be possible in both 
cases but currently fails for static calls due to a bug in PHP.

The documentation indeed supports the case for this bug report, but to defend 
der...@php.net as well: the first part of his response is probably a template 
text when marking a report as "Not a bug". The rest of his message does not 
mention static calling, which is essential for the problem to occur, so I think 
he closed the report because he missed that point. Please let us know, because 
the current status is very confusing.


[2011-02-21 19:35:10] php dot net at phrozenbyte dot de

I support this re-opening-request... Since 5.3 __autoload() is definitly *not* 
"the last line of defense for PHP to find a class definition". That's simply 
wrong.

http://www.php.net/manual/en/language.oop5.autoload.php (Note #1 + Example #3)
http://www.php.net/manual/en/language.oop5.changelog.php (#5)


[2011-02-19 23:06:12] michael at squiloople dot com

Here's a request to re-open the bug, for it is indeed a bug: exceptions can be 
thrown and caught if the method called is _not_ static, as documented, but 
cannot 
be thrown and caught if the method _is_ static (and where the class name is not 
a 
variable), which is both inconsistent and against the documentation. It is 
_unexpected_ behaviour.


[2011-02-16 15:31:49] madboyka at yahoo dot com

To: der...@php.net
I don't think you've read the documentation on autoloading yourself:
http://www.php.net/manual/en/language.oop5.autoload.php

The first note states that since PHP 5.3, you may throw an exception from the 
autoload function (even if the class can be loaded) and catch that exception 
without a problem. Examples #3 and #4 in the documentation entry demonstrate 
this. This works when the autoload function gets invoked when instantiating a 
class, but doesn't when you make a static call on it. This behavior is not 
consistent.
Also, take a look at michael@...'s workaround, which unexpectedly works great. 
And don't tell me that PHP behaves as "expected".

I understand, that this is not a major bug, we all can live without a fix, but 
at least mark it as to be fixed in the far future.


[2011-02-16 11:24:38] der...@php.net

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

FWIW, this is "expected". The __autoload() method is the last line of defense 
for PHP to find a class definition. If it can't find it, PHP bails out with a 
fatal error. If you throw an exception, you basically abort this final chance, 
and thus gives PHP you that fatal "can not find class" error. However, you can 
catch the exception in the __autoload() method,




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=52412


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

Bug #63405 [Opn]: Segfault with traits and namespaces and as operator

2012-10-31 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=63405&edit=1

 ID: 63405
 Updated by: larue...@php.net
 Reported by:mbret...@php.net
 Summary:Segfault with traits and namespaces and as operator
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Ubuntu 12.04 32bit
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

could you give us a complete test script?


Previous Comments:

[2012-10-31 09:30:49] mbret...@php.net

Description:

It looks like that this segfault occurs on every second request, when using 
namespaces + traits + autloader + 'as' operator.

Without 'as' op it works.


Test script:
---
_setQueryParam($query, $p, $op, $v);
}
}   

...
}

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
4029/build/buildd/php5-5.4.8/Zend/zend_compile.c: No such file or directory.
(gdb) bt
#0  zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
#1  0xb6785bab in ZEND_BIND_TRAITS_SPEC_HANDLER (execute_data=0xb75ab04c) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:1027
#2  0xb67bc975 in execute (op_array=0xb67442a6) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#3  0xb67442a6 in zend_call_function (fci=0x0, fci_cache=0x0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:958
#4  0xb676abd4 in zend_call_method (object_pp=, obj_ce=, 
fn_proxy=, function_name=, 
function_name_len=, retval_ptr_ptr=, 
param_count=, arg1=, 
arg2=) 
at /build/buildd/php5-5.4.8/Zend/zend_interfaces.c:97
#5  0xb662772a in zif_spl_autoload_call (ht=0, return_value=0x1, 
return_value_ptr=0x80225b58, this_ptr=0x0, return_value_used=-2145232000) at 
/build/buildd/php5-5.4.8/ext/spl/php_spl.c:436
#6  0xb6744379 in zend_call_function (fci=0x5283354c, fci_cache=0xbfffcd0b) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:980
#7  0xb6744b8d in zend_lookup_class_ex (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, key=0x0, 
use_autoload=1, ce=0xbfffcda0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1127
#8  0xb6744d4b in zend_lookup_class (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, 
ce=0xbfffcda0) at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1152
#9  0xb6764d21 in zif_class_exists (ht=2, return_value=0x80225924, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/build/buildd/php5-5.4.8/Zend/zend_builtin_functions.c:1233
#10 0xb6800dfa in zend_do_fcall_common_helper_SPEC (execute_data=0xb75aa9f0) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:642
#11 0xb67bc975 in execute (op_array=0xb6753729) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#12 0xb6753729 in zend_execute_scripts (type=0, retval=0xb164, 
file_count=0) at /build/buildd/php5-5.4.8/Zend/zend.c:1309
#13 0xb66ecdae in php_execute_script (primary_file=0xb164) at 
/build/buildd/php5-5.4.8/main/main.c:2482
#14 0xb68036c0 in php_handler (r=0xb2c61888) at 
/build/buildd/php5-5.4.8/sapi/apache2handler/sapi_apache2.c:682







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

Bug #62738 [Csd->Nab]: max_input_vars and stream upload

2012-10-31 Thread rasmus 
Edit report at https://bugs.php.net/bug.php?id=62738&edit=1

 ID: 62738
 Updated by: ras...@php.net
 Reported by:david at davidsteinsland dot net
 Summary:max_input_vars and stream upload
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   CentOS 6.2
 PHP Version:5.4.5
 Block user comment: N
 Private report: N



Previous Comments:

[2012-10-31 10:07:04] david at davidsteinsland dot net

The solution was posted recently on Stackoverflow:
http://stackoverflow.com/a/13089138/414414

The directive "enable_post_data_reading" was set to "Off", to prevent PHP from 
parsing the input data and populating $_POST and $_FILES. The max_input_vars 
does not need to be incremented.


[2012-10-31 10:06:15] david at davidsteinsland dot net

The solution was posted recently on Stackoverflow:
http://stackoverflow.com/a/13089138/414414

The directive "enable_post_data_reading" was set to "Off", to prevent PHP from 
parsing the input data and populating $_POST and $_FILES. The max_input_vars 
does not need to be incremented.


[2012-08-03 12:07:12] david at davidsteinsland dot net

Description:

When I try to upload files from Java through PHP, the logs give me messages 
about:
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.

Test script:
---
// read file contents from stream, and copy into a temporary file in order to 
get filesize
$putdata = fopen("php://input", "r");
$tmp = tmpfile();
$filesize = stream_copy_to_stream ($putdata, $tmp);
fclose ($putdata);

// move file to correct position
$target = fopen($filepath, "w");
fseek($tmp, 0, SEEK_SET);
stream_copy_to_stream($tmp, $target);
fclose($target);
fclose ($tmp);

Actual result:
--
Input variables exceeded 6000. To increase the limit change max_input_vars in 
php.ini. in Unknown on line 0.






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

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

2012-10-31 Thread evert at rooftopsolutions dot nl 
Edit report at https://bugs.php.net/bug.php?id=55815&edit=1

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

 New Comment:

I just wanted to chime in this one..

I personally think that while having a _POST superglobal is convenient (and 
needed, for BC) it's not necessarily a great design pattern. Especially in the 
case where you actually want access to php://input, but PHP pre-emptively 
decided to parse it, and I'm left with an empty stream.

So instead of extending this pattern to other HTTP methods (and don't kid 
yourself, there's a bunch more than just PUT [1]), I feel a much better 
alternative would be to expose the API that can actually parse 
multipart/form-data and takes a stream as input.

I feel this would solve the OP's use-case, is more flexible, and avoids the 
creation of additional evil super-globals.

  [1] http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-10


Previous Comments:

[2012-10-22 05:23:06] tylerromeo at gmail dot com

The http/1.1 RFC does not specify any data type for the request body of any 
request type, nor does the RFC for multipart/form-data specify the request type 
it must be used with in HTTP. And as has been demonstrated by previous 
comments, 
there exist legitimate cases where multipart/form-data would be useful in a PUT 
request.

Let me first say that putting PUT data into $_POST is a bad idea. Hopefully 
that 
is obvious enough. If this were to be implemented, it should use $_PUT (and 
$_FILES, if necessary, along with it).

The real question that needs to be asked is whether it's worth implementing. 
Technically, POST requests do not have any restriction on data types either. So 
really we could just tell all web developers to parse their POST requests from 
stdin like is suggested here for PUT. The reason PHP doesn't do that is because 
POST data is so often encoded in a standard data format and used as such that 
it 
helps developers tremendously to not force them to do such transformations 
themselves.

So the issue is whether enough users will be using multipart/form-data in PUT 
requests to warrant developers implementing a feature for it. Personally, I'm a 
fan of uniformity, and I believe that if we're parsing the request body for a 
POST request, then a PUT request should be treated no differently unless the 
spec has a restriction (which it doesn't).


[2012-07-08 18:38:30] johnston dot joshua at gmail dot com

Hi,

in regards to RFC 2616 and the comment:

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

This section addresses the meaning of the request URI and NOT the request body. 

In a POST request, the request URI should point to an entity that HANDLES the 
request body in whichever way it sees fit. This COULD be by appending the 
enclosed entity as an annotation to the given request URI, or appending a new 
entity to a collection, etc.

In a PUT request, the enclosed entity should BE STORED AT or REPLACE the entity 
that exists at the given request URI.

There is no reason why the Entity in question cannot be a multipart entity.

Here is a real-world example to illustrate this point using a messageboard as 
an 
example.

A User creates a new topic:

(minimal headers shown for brevity)

POST /topics HTTP/1.1
Content-Type: multipart/form-data; boundary=--
-11401160922046879112964562566
Content-Length: ???
-11401160922046879112964562566
Content-Disposition: form-data; name="comment"

This is a comment here
-11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png

[binary image data here]
-11401160922046879112964562566--


HTTP/1.1 201 Created
Location: /topics/1


Now we have a new topic referenced by /topics/1. Lets say the original user 
wants 
to change his topic. HTTP says that you can use a PUT request to a given 
request 
URI to replace an entity. If I wanted to replace the entity containing an image 
and the comment I would issue

PUT /topics/1 HTTP/1.1
Content-Type: multipart/form-data; boundary=--
-11401160922046879112964562566
Content-Length: ???
-11401160922046879112964562566
Content-Disposition: form-data; name="comment"

This is a comment here
-11401160922046879112964562566
Content-Disposition: form-dat

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

2012-10-31 Thread catch dot dave at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=55815&edit=1

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

 New Comment:

Whilst evert's example of providing access to the API might solve my original 
issue, I would still lean 
towards creating a new superglobal called _PUT.

1. PHP already has too many inconsistencies, let's not introduce another one. 
POST, GET exist, adding PUT 
is an obvious and consistant addition. Unless you wanted to deprecate existing 
superglobals over time, I 
would strongly suggest against providing a new way to do the same thing.
2. Whilst there are other HTTP methods, very few of them require/support 
parsing 
multi-form data like POST 
and PUT do (think of PATCH, DELETE, HEAD, etc).


Previous Comments:

[2012-10-31 15:09:47] evert at rooftopsolutions dot nl

I just wanted to chime in this one..

I personally think that while having a _POST superglobal is convenient (and 
needed, for BC) it's not necessarily a great design pattern. Especially in the 
case where you actually want access to php://input, but PHP pre-emptively 
decided to parse it, and I'm left with an empty stream.

So instead of extending this pattern to other HTTP methods (and don't kid 
yourself, there's a bunch more than just PUT [1]), I feel a much better 
alternative would be to expose the API that can actually parse 
multipart/form-data and takes a stream as input.

I feel this would solve the OP's use-case, is more flexible, and avoids the 
creation of additional evil super-globals.

  [1] http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-10


[2012-10-22 05:23:06] tylerromeo at gmail dot com

The http/1.1 RFC does not specify any data type for the request body of any 
request type, nor does the RFC for multipart/form-data specify the request type 
it must be used with in HTTP. And as has been demonstrated by previous 
comments, 
there exist legitimate cases where multipart/form-data would be useful in a PUT 
request.

Let me first say that putting PUT data into $_POST is a bad idea. Hopefully 
that 
is obvious enough. If this were to be implemented, it should use $_PUT (and 
$_FILES, if necessary, along with it).

The real question that needs to be asked is whether it's worth implementing. 
Technically, POST requests do not have any restriction on data types either. So 
really we could just tell all web developers to parse their POST requests from 
stdin like is suggested here for PUT. The reason PHP doesn't do that is because 
POST data is so often encoded in a standard data format and used as such that 
it 
helps developers tremendously to not force them to do such transformations 
themselves.

So the issue is whether enough users will be using multipart/form-data in PUT 
requests to warrant developers implementing a feature for it. Personally, I'm a 
fan of uniformity, and I believe that if we're parsing the request body for a 
POST request, then a PUT request should be treated no differently unless the 
spec has a restriction (which it doesn't).


[2012-07-08 18:38:30] johnston dot joshua at gmail dot com

Hi,

in regards to RFC 2616 and the comment:

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

This section addresses the meaning of the request URI and NOT the request body. 

In a POST request, the request URI should point to an entity that HANDLES the 
request body in whichever way it sees fit. This COULD be by appending the 
enclosed entity as an annotation to the given request URI, or appending a new 
entity to a collection, etc.

In a PUT request, the enclosed entity should BE STORED AT or REPLACE the entity 
that exists at the given request URI.

There is no reason why the Entity in question cannot be a multipart entity.

Here is a real-world example to illustrate this point using a messageboard as 
an 
example.

A User creates a new topic:

(minimal headers shown for brevity)

POST /topics HTTP/1.1
Content-Type: multipart/form-data; boundary=--
-11401160922046879112964562566
Content-Length: ???
-11401160922046879112964562566
Content-Disposition: form-data; name="comment"

This is a comment here
-11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png

[binary image data here]
--

Bug #63241 [Com]: PHP fails to open Windows deduplicated files

2012-10-31 Thread daniel dot stelter-gliese at innogames dot de 
Edit report at https://bugs.php.net/bug.php?id=63241&edit=1

 ID: 63241
 Comment by: daniel dot stelter-gliese at innogames dot de
 Reported by:daniel dot stelter-gliese at innogames dot de
 Summary:PHP fails to open Windows deduplicated files
 Status: Assigned
 Type:   Bug
 Package:Win32API related
 Operating System:   Windows Server 2012
 PHP Version:5.4.7
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

Any updates on this issue? Will it be merged?


Previous Comments:

[2012-10-12 21:59:56] mattfic...@php.net

The most recent patch fixes this bug for me using 5.4.7 TS and Win7sp1x64 and 
Win2k12.


[2012-10-12 13:56:52] daniel dot stelter-gliese at innogames dot de

Sorry for the compile error, I was in a bit of a hurry when I uploaded it.
Not only was a } missing, but also an assignment to isabsolute. Looking at the 
code this might be the reason why it fails.

I've updated the patch.


[2012-10-10 21:53:28] mattfic...@php.net

The patch doesn't compile.

Fixing the missing }, the patch doesn't work for me. I can still reproduce the 
bug.


[2012-10-10 08:27:16] paj...@php.net

Thanks for the very good report :) We can reproduce it and added it to our 
tests 
suite.

I'd to see how to deal with deduplicated files, if we have to cache them the 
same 
way we do for links or mounted volumes (necessary for require_once and the 
likes).


[2012-10-09 08:03:54] paj...@php.net

Matt, can you try to reproduce it please?




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=63241


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

Bug #62479 [Com]: PDO-psql cannot connect if password contains spaces

2012-10-31 Thread willfi...@php.net 
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1

 ID: 62479
 Comment by: willfi...@php.net
 Reported by:brice at bmaron dot net
 Summary:PDO-psql cannot connect if password contains spaces
 Status: Verified
 Type:   Bug
 Package:PDO related
 Operating System:   Linux- Debian Stable
 PHP Version:5.3.14
 Assigned To:willfitch
 Block user comment: N
 Private report: N

 New Comment:

Thanks Iliaa -

I will update the pull request to take into account escaping backslashes as 
well.


Previous Comments:

[2012-10-31 01:53:20] il...@php.net

I think the attached patch maybe slightly better than the one proposed, the 
attached patch also accounts for passwords that may contain \ character inside 
them.


[2012-10-31 01:51:40] il...@php.net

The following patch has been added/updated:

Patch Name: PDOPostgreSQLPassword
Revision:   1351648300
URL:
https://bugs.php.net/patch-display.php?bug=62479&patch=PDOPostgreSQLPassword&revision=1351648300


[2012-09-20 20:12:00] willfi...@php.net

Pull request for this bug has been submitted at: https://github.com/php/php-
src/pull/199.


[2012-09-17 19:39:08] willfi...@php.net

I have confirmed your findings. Let me do a little sniffing around and see what 
I 
can come up with.


[2012-07-04 12:29:56] brice at bmaron dot net

It seems to be a pdo-psql only ... not affecting other drivers like mysql




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=62479


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

Bug #63405 [Com]: Segfault with traits and namespaces and as operator

2012-10-31 Thread mbret...@php.net 
Edit report at https://bugs.php.net/bug.php?id=63405&edit=1

 ID: 63405
 Comment by: mbret...@php.net
 Reported by:mbret...@php.net
 Summary:Segfault with traits and namespaces and as operator
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Ubuntu 12.04 32bit
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

I could reduce it to the relevant files:
http://www.1401.at/phpcrash.tgz

=> just invoke index.php several times, the crash occurs reliably ;)


Previous Comments:

[2012-10-31 14:39:43] larue...@php.net

could you give us a complete test script?


[2012-10-31 09:30:49] mbret...@php.net

Description:

It looks like that this segfault occurs on every second request, when using 
namespaces + traits + autloader + 'as' operator.

Without 'as' op it works.


Test script:
---
_setQueryParam($query, $p, $op, $v);
}
}   

...
}

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
4029/build/buildd/php5-5.4.8/Zend/zend_compile.c: No such file or directory.
(gdb) bt
#0  zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
#1  0xb6785bab in ZEND_BIND_TRAITS_SPEC_HANDLER (execute_data=0xb75ab04c) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:1027
#2  0xb67bc975 in execute (op_array=0xb67442a6) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#3  0xb67442a6 in zend_call_function (fci=0x0, fci_cache=0x0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:958
#4  0xb676abd4 in zend_call_method (object_pp=, obj_ce=, 
fn_proxy=, function_name=, 
function_name_len=, retval_ptr_ptr=, 
param_count=, arg1=, 
arg2=) 
at /build/buildd/php5-5.4.8/Zend/zend_interfaces.c:97
#5  0xb662772a in zif_spl_autoload_call (ht=0, return_value=0x1, 
return_value_ptr=0x80225b58, this_ptr=0x0, return_value_used=-2145232000) at 
/build/buildd/php5-5.4.8/ext/spl/php_spl.c:436
#6  0xb6744379 in zend_call_function (fci=0x5283354c, fci_cache=0xbfffcd0b) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:980
#7  0xb6744b8d in zend_lookup_class_ex (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, key=0x0, 
use_autoload=1, ce=0xbfffcda0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1127
#8  0xb6744d4b in zend_lookup_class (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, 
ce=0xbfffcda0) at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1152
#9  0xb6764d21 in zif_class_exists (ht=2, return_value=0x80225924, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/build/buildd/php5-5.4.8/Zend/zend_builtin_functions.c:1233
#10 0xb6800dfa in zend_do_fcall_common_helper_SPEC (execute_data=0xb75aa9f0) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:642
#11 0xb67bc975 in execute (op_array=0xb6753729) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#12 0xb6753729 in zend_execute_scripts (type=0, retval=0xb164, 
file_count=0) at /build/buildd/php5-5.4.8/Zend/zend.c:1309
#13 0xb66ecdae in php_execute_script (primary_file=0xb164) at 
/build/buildd/php5-5.4.8/main/main.c:2482
#14 0xb68036c0 in php_handler (r=0xb2c61888) at 
/build/buildd/php5-5.4.8/sapi/apache2handler/sapi_apache2.c:682







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

Bug #63405 [Com]: Segfault with traits and namespaces and as operator

2012-10-31 Thread mbret...@php.net 
Edit report at https://bugs.php.net/bug.php?id=63405&edit=1

 ID: 63405
 Comment by: mbret...@php.net
 Reported by:mbret...@php.net
 Summary:Segfault with traits and namespaces and as operator
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Ubuntu 12.04 32bit
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

ok, I've found that the problem disappears, if I'm disabling APC, so this bug 
seems to be APC related.

So you can close this Bug.


Previous Comments:

[2012-10-31 20:59:39] mbret...@php.net

I could reduce it to the relevant files:
http://www.1401.at/phpcrash.tgz

=> just invoke index.php several times, the crash occurs reliably ;)


[2012-10-31 14:39:43] larue...@php.net

could you give us a complete test script?


[2012-10-31 09:30:49] mbret...@php.net

Description:

It looks like that this segfault occurs on every second request, when using 
namespaces + traits + autloader + 'as' operator.

Without 'as' op it works.


Test script:
---
_setQueryParam($query, $p, $op, $v);
}
}   

...
}

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
4029/build/buildd/php5-5.4.8/Zend/zend_compile.c: No such file or directory.
(gdb) bt
#0  zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
#1  0xb6785bab in ZEND_BIND_TRAITS_SPEC_HANDLER (execute_data=0xb75ab04c) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:1027
#2  0xb67bc975 in execute (op_array=0xb67442a6) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#3  0xb67442a6 in zend_call_function (fci=0x0, fci_cache=0x0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:958
#4  0xb676abd4 in zend_call_method (object_pp=, obj_ce=, 
fn_proxy=, function_name=, 
function_name_len=, retval_ptr_ptr=, 
param_count=, arg1=, 
arg2=) 
at /build/buildd/php5-5.4.8/Zend/zend_interfaces.c:97
#5  0xb662772a in zif_spl_autoload_call (ht=0, return_value=0x1, 
return_value_ptr=0x80225b58, this_ptr=0x0, return_value_used=-2145232000) at 
/build/buildd/php5-5.4.8/ext/spl/php_spl.c:436
#6  0xb6744379 in zend_call_function (fci=0x5283354c, fci_cache=0xbfffcd0b) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:980
#7  0xb6744b8d in zend_lookup_class_ex (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, key=0x0, 
use_autoload=1, ce=0xbfffcda0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1127
#8  0xb6744d4b in zend_lookup_class (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, 
ce=0xbfffcda0) at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1152
#9  0xb6764d21 in zif_class_exists (ht=2, return_value=0x80225924, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/build/buildd/php5-5.4.8/Zend/zend_builtin_functions.c:1233
#10 0xb6800dfa in zend_do_fcall_common_helper_SPEC (execute_data=0xb75aa9f0) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:642
#11 0xb67bc975 in execute (op_array=0xb6753729) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#12 0xb6753729 in zend_execute_scripts (type=0, retval=0xb164, 
file_count=0) at /build/buildd/php5-5.4.8/Zend/zend.c:1309
#13 0xb66ecdae in php_execute_script (primary_file=0xb164) at 
/build/buildd/php5-5.4.8/main/main.c:2482
#14 0xb68036c0 in php_handler (r=0xb2c61888) at 
/build/buildd/php5-5.4.8/sapi/apache2handler/sapi_apache2.c:682







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

Bug #63405 [Com]: Segfault with traits and namespaces and as operator

2012-10-31 Thread mbret...@php.net 
Edit report at https://bugs.php.net/bug.php?id=63405&edit=1

 ID: 63405
 Comment by: mbret...@php.net
 Reported by:mbret...@php.net
 Summary:Segfault with traits and namespaces and as operator
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Ubuntu 12.04 32bit
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

after Upgrading APC from 3.1.11 to 3.1.13 the crash does not occur anymore :D


Previous Comments:

[2012-10-31 21:10:54] mbret...@php.net

ok, I've found that the problem disappears, if I'm disabling APC, so this bug 
seems to be APC related.

So you can close this Bug.


[2012-10-31 20:59:39] mbret...@php.net

I could reduce it to the relevant files:
http://www.1401.at/phpcrash.tgz

=> just invoke index.php several times, the crash occurs reliably ;)


[2012-10-31 14:39:43] larue...@php.net

could you give us a complete test script?


[2012-10-31 09:30:49] mbret...@php.net

Description:

It looks like that this segfault occurs on every second request, when using 
namespaces + traits + autloader + 'as' operator.

Without 'as' op it works.


Test script:
---
_setQueryParam($query, $p, $op, $v);
}
}   

...
}

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
4029/build/buildd/php5-5.4.8/Zend/zend_compile.c: No such file or directory.
(gdb) bt
#0  zend_do_bind_traits (ce=0xb6c0873c) at 
/build/buildd/php5-5.4.8/Zend/zend_compile.c:4029
#1  0xb6785bab in ZEND_BIND_TRAITS_SPEC_HANDLER (execute_data=0xb75ab04c) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:1027
#2  0xb67bc975 in execute (op_array=0xb67442a6) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#3  0xb67442a6 in zend_call_function (fci=0x0, fci_cache=0x0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:958
#4  0xb676abd4 in zend_call_method (object_pp=, obj_ce=, 
fn_proxy=, function_name=, 
function_name_len=, retval_ptr_ptr=, 
param_count=, arg1=, 
arg2=) 
at /build/buildd/php5-5.4.8/Zend/zend_interfaces.c:97
#5  0xb662772a in zif_spl_autoload_call (ht=0, return_value=0x1, 
return_value_ptr=0x80225b58, this_ptr=0x0, return_value_used=-2145232000) at 
/build/buildd/php5-5.4.8/ext/spl/php_spl.c:436
#6  0xb6744379 in zend_call_function (fci=0x5283354c, fci_cache=0xbfffcd0b) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:980
#7  0xb6744b8d in zend_lookup_class_ex (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, key=0x0, 
use_autoload=1, ce=0xbfffcda0) at 
/build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1127
#8  0xb6744d4b in zend_lookup_class (name=0x802278a8 
"app\\modules\\backend\\rest\\controllers\\Language", name_length=45, 
ce=0xbfffcda0) at /build/buildd/php5-5.4.8/Zend/zend_execute_API.c:1152
#9  0xb6764d21 in zif_class_exists (ht=2, return_value=0x80225924, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/build/buildd/php5-5.4.8/Zend/zend_builtin_functions.c:1233
#10 0xb6800dfa in zend_do_fcall_common_helper_SPEC (execute_data=0xb75aa9f0) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:642
#11 0xb67bc975 in execute (op_array=0xb6753729) at 
/build/buildd/php5-5.4.8/Zend/zend_vm_execute.h:410
#12 0xb6753729 in zend_execute_scripts (type=0, retval=0xb164, 
file_count=0) at /build/buildd/php5-5.4.8/Zend/zend.c:1309
#13 0xb66ecdae in php_execute_script (primary_file=0xb164) at 
/build/buildd/php5-5.4.8/main/main.c:2482
#14 0xb68036c0 in php_handler (r=0xb2c61888) at 
/build/buildd/php5-5.4.8/sapi/apache2handler/sapi_apache2.c:682







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

Bug #63400 [Opn->Nab]: Multi_Curl does not work, single curl does

2012-10-31 Thread pierrick 
Edit report at https://bugs.php.net/bug.php?id=63400&edit=1

 ID: 63400
 Updated by: pierr...@php.net
 Reported by:contact at wimbledon-it dot co dot uk
 Summary:Multi_Curl does not work, single curl does
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:cURL related
 Operating System:   Windows 7 64
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Same as #61141


Previous Comments:

[2012-10-30 15:36:43] contact at wimbledon-it dot co dot uk

Description:

The code provided runs on 5.3.6 perfectly and returns the google.co.uk and 
reddit.com source code. 

The curl version provided is 7.24 - that a version from January 2012. There is 
already 7.28 available. It has not been tested with another version then the 
one 
that is provided by PHP.


Test script:
---
http://pastebin.com/7S5ScDYJ

Expected result:

Should be able to see the Google and Reddit website.

Actual result:
--
it exceeds the execution time OR 
Warning: (null)(): 10 is not a valid cURL handle resource in Unknown on line 0 
OR 
Warning: (null)(): 65 is not a valid cURL handle resource in Unknown on line 0


The same happens in 5.3.18







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

Bug #63241 [Asn->Csd]: PHP fails to open Windows deduplicated files

2012-10-31 Thread ab 
Edit report at https://bugs.php.net/bug.php?id=63241&edit=1

 ID: 63241
 Updated by: a...@php.net
 Reported by:daniel dot stelter-gliese at innogames dot de
 Summary:PHP fails to open Windows deduplicated files
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Win32API related
 Operating System:   Windows Server 2012
 PHP Version:5.4.7
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a2e4404bc8155e6b6d9deefa22a172857d4b5e08
Log: Fixed bug #63241 PHP fails to open Windows deduplicated files.


Previous Comments:

[2012-10-31 17:53:49] daniel dot stelter-gliese at innogames dot de

Any updates on this issue? Will it be merged?


[2012-10-12 21:59:56] mattfic...@php.net

The most recent patch fixes this bug for me using 5.4.7 TS and Win7sp1x64 and 
Win2k12.


[2012-10-12 13:56:52] daniel dot stelter-gliese at innogames dot de

Sorry for the compile error, I was in a bit of a hurry when I uploaded it.
Not only was a } missing, but also an assignment to isabsolute. Looking at the 
code this might be the reason why it fails.

I've updated the patch.


[2012-10-10 21:53:28] mattfic...@php.net

The patch doesn't compile.

Fixing the missing }, the patch doesn't work for me. I can still reproduce the 
bug.


[2012-10-10 08:27:16] paj...@php.net

Thanks for the very good report :) We can reproduce it and added it to our 
tests 
suite.

I'd to see how to deal with deduplicated files, if we have to cache them the 
same 
way we do for links or mounted volumes (necessary for require_once and the 
likes).




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=63241


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

Bug #62444 [Com]: Handle leak in is_readable

2012-10-31 Thread vseticka dot martin at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=62444&edit=1

 ID: 62444
 Comment by: vseticka dot martin at gmail dot com
 Reported by:sergio dot nalin at gmail dot com
 Summary:Handle leak in is_readable
 Status: Assigned
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Win 7 64bit
 PHP Version:5.3.14
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Is there any progress? This issue makes PHP really hard to use on Windows.


Previous Comments:

[2012-07-26 17:24:41] mr_pain at operamail dot com

Memory leak confirmed for the following configurations:

PHP vc9 5.3.15, thread safe version + Apache Httpd 2.4.2 + Win XP SP3 
PHP vc9 5.4.5,  thread safe version + Apache Httpd 2.4.2 + Win XP SP3 

Running Test script:

for($i=0; $i<100;$i++) {
  is_readable("c:\\temp");
}

PHP vc9 5.4.5 tested on WAMP stacks:


XAMPP USB Lite 1.8.0(Windows XP SP3)
Uniform Server 8.5.8-Coral  (Windows XP SP3)

For details see:
http://forum.uniformserver.com/index.php?showtopic=2627&hl=

Windows 7 SP1 and Windows Server 2008 R2 (both is 64-bit OS)

I agree with above comment, it makes running PHP on a Windows production server 
impractical.


[2012-07-25 22:26:05] smiles_indonesia at yahoo dot co dot id

It seems happened since introduction of php 5.3.0. If you see in the changelogs:

http://www.php.net/ChangeLog-5.php

Added support for ACL (is_writable, is_readable, reports now correct results) 
on Windows. (Pierre, Venkat Raman Don, Kanwaljeet Singla)

This issue is very critical, because it makes php running on windows production 
server impractical / unusable...

My quad xeon box becomes very slow after some days, the ram usage is 
mysteriously increased (httpd process usage still remains the same, I thought 
handle consumes kernel spaces)...

If your webserver servers 1 million request, then there will be about 1 million 
handle opened... Usual application only consumes 20 to 2000 handles...


[2012-06-29 00:10:17] sergio dot nalin at gmail dot com

Description:

PHP vc9 5.3.14, thread safe version + Apache Httpd 2.2.22 + Win 7/Win Server 
2008 
R2

Each time is_readable in invoked, it leaves an open handle in the httpd process.



Test script:
---
for($i=0; $i<100;$i++) {
  is_readable("c:\\temp");
}

NOTE: the folder/file must exist for the leak to happen.

Expected result:

No leaked handles

Actual result:
--
100 leaked handles






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

Bug #63241 [Com]: PHP fails to open Windows deduplicated files

2012-10-31 Thread mattfic...@php.net 
Edit report at https://bugs.php.net/bug.php?id=63241&edit=1

 ID: 63241
 Comment by: mattfic...@php.net
 Reported by:daniel dot stelter-gliese at innogames dot de
 Summary:PHP fails to open Windows deduplicated files
 Status: Closed
 Type:   Bug
 Package:Win32API related
 Operating System:   Windows Server 2012
 PHP Version:5.4.7
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

Your patch has been committed to all PHP branches (5.3, 5.4, master(php 5.5))

If its not included in the next release (because it may be committed after the 
revision chosen for release), it should be in the one after that.

Thank you very much for noticing this problem and fixing it. Thank you for 
making PHP better.


Previous Comments:

[2012-10-31 22:11:07] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a2e4404bc8155e6b6d9deefa22a172857d4b5e08
Log: Fixed bug #63241 PHP fails to open Windows deduplicated files.


[2012-10-31 22:03:42] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a2e4404bc8155e6b6d9deefa22a172857d4b5e08
Log: Fixed bug #63241 PHP fails to open Windows deduplicated files.


[2012-10-31 17:53:49] daniel dot stelter-gliese at innogames dot de

Any updates on this issue? Will it be merged?


[2012-10-12 21:59:56] mattfic...@php.net

The most recent patch fixes this bug for me using 5.4.7 TS and Win7sp1x64 and 
Win2k12.


[2012-10-12 13:56:52] daniel dot stelter-gliese at innogames dot de

Sorry for the compile error, I was in a bit of a hurry when I uploaded it.
Not only was a } missing, but also an assignment to isabsolute. Looking at the 
code this might be the reason why it fails.

I've updated the patch.




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=63241


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

[PHP-BUG] Bug #63407 [NEW]: segmentation fault in zval_mark_grey()

2012-10-31 Thread ber...@php.net 
From: berdir
Operating system: linux
PHP version:  5.4.8
Package:  Reproducible crash
Bug Type: Bug
Bug description:segmentation fault in zval_mark_grey()

Description:

I'm experiencing segfaults in the mentioned function while working on
Drupal 8. 
Here's what I found out so far:

- Happens both with the default ubuntu 12.04 php 5.3.10 and php 5.4.8 from

https://launchpad.net/~ondrej/+archive/php5
- See http://drupal.org/node/512026#comment-6673974 for the backtrace
- Happens both on my local installation and our automated testbots
- The segfault does not happen if zend.enable_gc is Off.

It's non-trivial to set up, see "script" below, so just tell me what
commands to 
run in gdb to give you additional information if required.

Test script:
---
git clone g...@git.drupal.org:project/drupal.git --branch=8.x
# Install Drupal, enable Testing module.
wget http://drupal.org/files/form-state-keyvalue-512026-98.patch
git apply form-state-keyvalue-512026-98.patch

php core/scripts/run-tests.sh --class
"Drupal\views\Tests\Handler\FilterStringTest"


Expected result:

Drupal test run
---

Tests to be run:
 -  (Drupal\views\Tests\Handler\FilterStringTest)

Test run started:
 Wednesday, October 31, 2012 - 23:50

Test summary


Filter: String n passes, 0 fails, and 0 exception

Test run duration: n sec

Actual result:
--
Drupal test run
---

Tests to be run:
 -  (Drupal\views\Tests\Handler\FilterStringTest)

Test run started:
 Wednesday, October 31, 2012 - 23:50

Test summary


Segmentation fault (core dumped)
FATAL Drupal\views\Tests\Handler\FilterStringTest: test runner returned a
non-
zero error code (139).
- Found database prefix 'simpletest916618' for test ID 372.
- Removed test files directory.
- Removed 43 leftover tables.

Test run duration: 11 sec


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

Req #38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache

2012-10-31 Thread oliver at realtsp dot com 
Edit report at https://bugs.php.net/bug.php?id=38915&edit=1

 ID: 38915
 Comment by: oliver at realtsp dot com
 Reported by:dimmoborgir at gmail dot com
 Summary:Apache: system() (and similar) don't cleanup opened
 handles of Apache
 Status: Analyzed
 Type:   Feature/Change Request
 Package:Program Execution
 Operating System:   UNIX
 PHP Version:5.2.2, 4.4.7
 Block user comment: N
 Private report: N

 New Comment:

we solved by passing the forked/exec'd process through a bash shell and closing 
all te file 
descriptors: eg: (note this is for FreeBSD using daemon, but "nohup" should 
work 
on linux)

daemon /usr/bin/env bash -c 'exec 0<&-; exec 1> /path/to/error/log; exec 2> 
/path/to/stdout/log; 
eval exec {3..255}\>\&-; /usr/bin/env php /path/to/script args...'

Note we find it crucial to redirect and NOT CLOSE STDOUT and STDERR because 
otherwise you will 
never find out if sth is wrong with forked process. You should ensure that they 
exist and are 
writable before forking. 

The trick with eval exec {3..255}\>\&-;  is from here:
http://blog.n01se.net/blog-n01se-net-p-145.html

This works for us in a php-fastcgi situation. the fastcgi-socket and the mysql 
socket are both 
closed successfully. the new process opens its own mysql socket just fine...

I suspect this is similar to what Jeroen's closedexec.c does, but no need for a 
c program. 
Everyone should have bash. 

If you redirect the stdout of above fork command to a file and check the 
contents of that daemon 
gives you nice messages, just append 

 2> /path/to/temp/stderr/file/for/daemon/messages

to the above command.

We have the construction of the fork command wrapped in a simple function, like 
so:

$exec_cmd = ((php_uname('s') == 'FreeBSD') ? 'daemon' : 'nohup') .  

// try to 
be OS agnostic, daemon = fork, setguid etc, but don't close stderr with -f  
   
  ' /usr/bin/env bash -c ' .

// wrap 
actual call to new php process in a shell (use env!), so
 
  // must escape here in case the already escaped args contain  

 
  // specials chars like single quotes (which the will!)

 
  escapeshellarg(
'exec 0<&-; ' . 

// close 
STDIN   

'exec 1> ' . escapeshellarg($app_log) . '; ' .  

// STDOUT 
> app_log   
>
'exec 2> ' . escapeshellarg($error_log) . '; ' .

// STDOUT 
> error_log 
>
'eval exec {3..255}\>\&-; ' .   

// we can 
close all other fds (fastcgi, mysql, etc)..eval trick!  
   
'/usr/bin/env php ' . BASE . $cmd . ' ' .   

// call 
php (with env!) don't rely on shebang or exec perms 
 
join(' ',   

// add 
args separated by spaces
  
 array_map(function ($arg) { return escapeshellarg($arg); }, 
$args))
// after 
escaping them   

);


Sorry about the formatting...


Previous Comments:

[2010-04-16 01:31:48] crrodriguez at opensuse dot org

In linux, this should fix the issue for mail()

diff --git a/ext/standard/mail.c b/ext/standard/mail.c
index ab65f16..a8b3bf5 100644
--- a/ext/standard/mail.c
+++ b/ext/standard/mail.c
@@ -288,8 +288,12 @@ PHPAPI int php_mail(char *to, char *subject, char 
*message, 
char *headers, char
 * (e.g. the shell can't be executed) we explicitely set it to 0 to be
 * sure we don't catch any older errno value. */
errno = 0;
+#if defined(__linux__) && defined(__GLIBC__) &&  __GLIBC_PREREQ(2, 9)
+   sendmail = popen(sendmail_cmd, "we");
+#else 
sendmail = popen(sendmail_cmd, "w");
 #endif
+#endif
if (extra_cmd != NULL) {
efree (sendmail_cmd);
}


Note that you need glibc 2.9 though.


[2010-02-22 19:16:37] ionut dot dumitru at webland dot ro

the problem is still there in 5.2 just with php not

Req #48358 [Com]: SplDoublyLinkedList needs an insertAfterIterator() method or something similar

2012-10-31 Thread dnwake at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=48358&edit=1

 ID: 48358
 Comment by: dnwake at gmail dot com
 Reported by:dannel at aaronexodus dot com
 Summary:SplDoublyLinkedList needs an insertAfterIterator()
 method or something similar
 Status: Assigned
 Type:   Feature/Change Request
 Package:SPL related
 PHP Version:5.3.0RC2
 Assigned To:colder
 Block user comment: N
 Private report: N

 New Comment:

This is ridiculous.  

Efficiency of inserting and deleting in the middle of the list is the main 
motivation for using a linked list in the first place.


Previous Comments:

[2011-04-15 21:23:51] omercan at gmail dot com

O(n) complexity should be expected from a list data structure along with no 
array access. The drawback of lists is they lack direct access to the elements 
by their position. Well, that's not the case with SplDoublyLinkedList because 
there's array access. So, it's a different implementation as far as it seems.

In my opinion, the problem with SplDoublyLinkedList is that the main operations 
are left to be implemented in the user land, which require iterating over the 
list in each. This class can be much more valuable if the following operations 
are included:

clear() -> clear all elements

remove($value) -> return number of removals b/c $value can be more than 1

sort(Closure $predicate) -> sort without keeping key association

swap($list) -> swap with another list or a Traversable instance

unique() -> return the unique values in the list, possibly in a new list


[2010-05-22 13:46:01] 1000235409 at smail dot shnu dot edn dot cn

i have encountered the same problem today, after this was modified for 1 year...

but i have a solution to solve this problem. write anohter class with a lots of 
spldoublylinkedlists inside it. however, complex algorithm may be used...


[2009-05-21 17:02:15] dannel at aaronexodus dot com

Description:

The SplDoublyLinkedList is great, but it lacks a way to insert a node somewhere 
in the middle of the list.

One could technically extend the class and provide that functionality, but due 
to the fact that there seem to be [documented] data members in 
SplDoublyLinkedList, the only way to do it would be to find the reference node, 
insert the new node, and move all of the following nodes up one slot in the 
list, resulting in O(n) performance for an insert.

I propose adding an insertAfterIterator() method which would place the new node 
after the current node the iterator points to.

Another option could be an insertAfterArrayKey() method which would act 
similarly, but would find the reference node via a given array key, which might 
be a little more straightforward to use in code.

Each should probably have an insertBefore*() counterpart as well.







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

Bug #63407 [Opn->Fbk]: segmentation fault in zval_mark_grey()

2012-10-31 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=63407&edit=1

 ID: 63407
 Updated by: larue...@php.net
 Reported by:ber...@php.net
 Summary:segmentation fault in zval_mark_grey()
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

there is a knew issue of segfault caused by traits alias.

please try with the 5.4-snapshot


Previous Comments:

[2012-10-31 22:55:43] ber...@php.net

Description:

I'm experiencing segfaults in the mentioned function while working on Drupal 8. 
Here's what I found out so far:

- Happens both with the default ubuntu 12.04 php 5.3.10 and php 5.4.8 from 
https://launchpad.net/~ondrej/+archive/php5
- See http://drupal.org/node/512026#comment-6673974 for the backtrace
- Happens both on my local installation and our automated testbots
- The segfault does not happen if zend.enable_gc is Off.

It's non-trivial to set up, see "script" below, so just tell me what commands 
to 
run in gdb to give you additional information if required.

Test script:
---
git clone g...@git.drupal.org:project/drupal.git --branch=8.x
# Install Drupal, enable Testing module.
wget http://drupal.org/files/form-state-keyvalue-512026-98.patch
git apply form-state-keyvalue-512026-98.patch

php core/scripts/run-tests.sh --class 
"Drupal\views\Tests\Handler\FilterStringTest"


Expected result:

Drupal test run
---

Tests to be run:
 -  (Drupal\views\Tests\Handler\FilterStringTest)

Test run started:
 Wednesday, October 31, 2012 - 23:50

Test summary


Filter: String n passes, 0 fails, and 0 exception

Test run duration: n sec

Actual result:
--
Drupal test run
---

Tests to be run:
 -  (Drupal\views\Tests\Handler\FilterStringTest)

Test run started:
 Wednesday, October 31, 2012 - 23:50

Test summary


Segmentation fault (core dumped)
FATAL Drupal\views\Tests\Handler\FilterStringTest: test runner returned a non-
zero error code (139).
- Found database prefix 'simpletest916618' for test ID 372.
- Removed test files directory.
- Removed 43 leftover tables.

Test run duration: 11 sec







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

Bug #63403 [Opn->Nab]: Segmentation fault with preg_match

2012-10-31 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=63403&edit=1

 ID: 63403
 Updated by: larue...@php.net
 Reported by:to dot yashin at gmail dot com
 Summary:Segmentation fault with preg_match
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux ubuntu
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

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

stack overflow, see #45735


Previous Comments:

[2012-10-31 06:44:35] to dot yashin at gmail dot com

Description:

reproduced on:
php 5.3.10
php 5.4.6

Test script:
---
$text = 
file_get_contents('http://dl.dropbox.com/u/31119503/php_segfault/data.txt');
preg_match('/(?:^.*$\n*)+/mx', $text);

Expected result:

preg_match return false

Actual result:
--
Segmentation fault (core dumped)






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

Bug #63281 [Com]: PDO: Multiple queries using multiple bindParams yields unexpected results

2012-10-31 Thread rawr at rawr dot com 
Edit report at https://bugs.php.net/bug.php?id=63281&edit=1

 ID: 63281
 Comment by: rawr at rawr dot com
 Reported by:jim dot gibbs at onelifemedia dot com
 Summary:PDO: Multiple queries using multiple bindParams
 yields unexpected results
 Status: Wont fix
 Type:   Bug
 Package:PDO related
 Operating System:   Mac
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

nihao


Previous Comments:

[2012-10-16 15:29:19] jim dot gibbs at onelifemedia dot com

Thanks for the information.  I read your blog post, and I'm glad that we came 
to 
the same conclusion.

I guess my only other question would be, are there any drawbacks to sending the 
array to the execute function?  That's the workaround that I'm currently using, 
and it's working just fine.  Of course, I haven't tried any speed/load tests, 
or 
anything of that ilk, since I'm in the beginning stages of development.


[2012-10-16 15:08:29] larue...@php.net

I wrote a blog to explain this: http://www.laruence.com/2012/10/16/2831.html

it's chinese, but I think you can use google translator :)


[2012-10-16 14:42:19] larue...@php.net

the reason for this is because require a reference variable, then in the loop, 
the variable will be reused, after the loop, the variable will be the last 
assigned one.

you can use bindValue instead, or ...
you can use:
foreach ($params as $key => &$val) ;

this is a complicated problem, since it is a feature of PHP 
internal(reference). 
so, won't fix.

thanks


[2012-10-15 18:18:17] jim dot gibbs at onelifemedia dot com

Description:

Created a prepared statement, with named placeholders.  The prepared statement 
contained 2 queries, and 3 placeholders.  2 of the placeholders were the same, 
so 
they *should* become the same value.

The resulting query ended up being all three place holders being the same value.

The results below were generated from the mysql log files.

Workaround:

Instead of using the bindParam function, I was able to send the same array to 
the 
execute function, and it worked.

Test script:
---
$query = <prepare($query);
$bind_params = array(':session_key' => $session_key, ':generated_hash' => 
$generated_hash)
foreach( $bind_params as $key => $value ){
  $statement->bindParam($key, $value);
}
$statement->execute();


Expected result:

DELETE FROM `authentication_hashes` WHERE session_key = '8675309';
INSERT INTO `authentication_hashes` (`session_key`, `generated_hash`) VALUES 
('8675309', 'cb5606644c1d30a9d8f84cee4234a44455c82448a33f8031434ec42a6d173383')


Actual result:
--
DELETE FROM `authentication_hashes` WHERE session_key = 
'3966b45ae07b86de9c74163b093994fbf2a5813a06cbc9902f15e1b38a212940';
INSERT INTO `authentication_hashes` (`session_key`, `generated_hash`) VALUES 
('3966b45ae07b86de9c74163b093994fbf2a5813a06cbc9902f15e1b38a212940', 
'3966b45ae07b86de9c74163b093994fbf2a5813a06cbc9902f15e1b38a212940')






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

[PHP-BUG] Bug #63408 [NEW]: implode bug

2012-10-31 Thread oxconcise at hotmail dot com 
From: oxconcise at hotmail dot com
Operating system: Windows Vista
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:implode bug

Description:

PHP 5.4.4

$b = array("one", "two", "three");
echo implode('<', $b);

outputs "one" 

Test script:
---
$b = array("one", "two", "three");
echo implode('<', $b);


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

Bug #63408 [Opn->Nab]: implode bug

2012-10-31 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=63408&edit=1

 ID: 63408
 Updated by: ahar...@php.net
 Reported by:oxconcise at hotmail dot com
 Summary:implode bug
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows Vista
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You are presumably outputting HTML, and your browser is treating the first < as 
the start of a HTML tag.


Previous Comments:

[2012-11-01 06:33:14] oxconcise at hotmail dot com

Description:

PHP 5.4.4

$b = array("one", "two", "three");
echo implode('<', $b);

outputs "one" 

Test script:
---
$b = array("one", "two", "three");
echo implode('<', $b);







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