Bug #52937 [Com]: call_user_func warning is inappropriate

2012-03-20 Thread georgir at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=52937&edit=1

 ID: 52937
 Comment by: georgir at gmail dot com
 Reported by:mryaggi at hotmail dot com
 Summary:call_user_func warning is inappropriate
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Seven
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

The "workaround" from the last comment is not a good idea, because it can not 
be applied generally. If you use call_user_func_array('foo', array(&$b)) when 
the function foo takes an argument by copy instead of by reference and modifies 
it thinking it doesn't matter, $b will still be modified, which is most 
certainly undesired.

Also, the issue is more serious than described in the original post. It affects 
call_user_func_array as well as call_user_func, and it is not just a warning 
that is given, but the whole function does not get executed. This is actually a 
big deal, it can break a lot of programs. A setting to allow execution of the 
function in this case would be welcome.


Previous Comments:

[2011-08-04 02:11:00] lucas at threeamdesign dot com

to work around this problem put the reference in the argument array. e.g.:

function foo(&$bar) {
$bar = 5;
}
$a = 1;
$b = 2;
call_user_func('foo', $a);
call_user_func_array('foo', array(&$b));
var_dump($a, $b);

gives

int(1)
int(5)


[2010-10-11 11:00:54] mryaggi at hotmail dot com

Ok, I'm going to keep it simple.

You say "[I] have to use call_user_func_array instead".
Please show me how.

Note : I'm just trying to avoid the warning properly.

This would be quite a solution :
call_user_func('ExprectRef',   &   $p);
call_user_func_array('ExprectRef',array(   &   $p));

But it's a pity you have to write & TWICE. One in the signature, one in the 
call_user_func call. 

...it looks so much like the depreciated call-time pass-by-reference.

Don't you think?


[2010-10-03 00:02:58] cataphr...@php.net

You *should* know whether the function takes references; it's part of its 
signature.

If it does take references you cannot use call_user_func, and have to use 
call_user_func_array instead.


[2010-09-29 19:31:10] mryaggi at hotmail dot com

Thank you for your quick reply.
You say : "Use call_user_func_array()."
But you can run the test script with call_user_func_array() instad, and still 
you will get those warnings.

My point is : when you call call_user_func you have no idea whether the 
function called expects references or not (values).

The only solution I see is to always give references to call_user_func*()

For ex:
-
function MY_call_user_func_array($Func,$Args)
{
  foreach(array_keys($Args) as $i) { $Args[$i] =& $Args[$i]; }//make it a ref
  call_user_func_array($Func,$Args);
}

function test(&$z){  echo "ok : " . $z . "\n";}
$a = 1;
MY_call_user_func_array('test',array($a));
-

And here we are! IT WORKS!
but it I feel like I just learnt how to poo in PHP...


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

Yes, this may be confusing. The problem is that the level of indirection added 
means when the function test() is actually called by the implementation of 
call_user_func() via zend_call_function, information about the arguments is 
lost. Use call_user_func_array().

Tests 1 and 3 are basically the same. The manual for call_user_func has a note:

«Note that the parameters for call_user_func() are not passed by reference.»

Since call_user_func doesn't receive its parameters by reference, by the time 
they reach it, it has no way of knowing if the parameters were sent by 
reference or not.

Test 2 is a different matter. But you are actually passing a reference to 
test() because zend_call_function() is nice and when you pass a non-reference 
to a function that expects a reference and the non-reference has refcount 1, it 
converts it into a reference. See

http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_execute_API.c#860

Again, this makes sense if you're writing an extension and using 
zend_call_function() and passing it a variable you've created. I don't see how 
this can be fixed, except by adding something like fci->no_separation that 
doesn't create a reference even if the refcount is 1. Not sure if it's worth 
the trouble.




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


-- 
Edit this bu

Req #61439 [Opn]: POST and other methods input data handling

2012-03-20 Thread mike 
Edit report at https://bugs.php.net/bug.php?id=61439&edit=1

 ID: 61439
 Updated by: m...@php.net
 Reported by:martin dot koranda at gmail dot com
 Summary:POST and other methods input data handling
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
-Operating System:   windows
+Operating System:   *
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I second that. Actually I've sitting an unfinished proposal in my Inbox' Drafts 
which addresses this issue.

BUT, I'm not thinking about php.ini, but SAPI code shouldn't care about the 
request method, but the request body's content type. And there should be an API 
to register content-type handlers.


Previous Comments:

[2012-03-19 17:36:38] martin dot koranda at gmail dot com

Description:

when sending multipart/form-data via a POST method, PHP internally parses all 
variables into $_POST and files into $_FILES. but the parsing is not done with 
any 
other method (PUT,PATCH,PROPFIND ..)

additionally, sending POST with multipart/form-data makes php://input 
unavailable.

so there is no universal parsing solution which covers all methods.

there should be a setting option (php.ini) where i can determine which 
particular 
methods i want the internal parser run for (eg.  "parse_input_methods = 
POST,PUT,PATCH")

and/or there should be an option for disabling that internal parser completely.







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

Req #60354 [Asn]: MYSQL_CLIENT_COMPRESS in php.ini

2012-03-20 Thread uw 
Edit report at https://bugs.php.net/bug.php?id=60354&edit=1

 ID: 60354
 Updated by: u...@php.net
 Reported by:spamik at yum dot pl
 Summary:MYSQL_CLIENT_COMPRESS in php.ini
 Status: Assigned
 Type:   Feature/Change Request
 Package:MySQL related
 PHP Version:5.3.8
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

I do not agree on the statement developers write genuie applications. Native 
interfaces are there to get most out of a specific interface/library from a 
specific application. As there is no security concern or severe performance 
impact, developer shall have full control. There's no need to differ from the 
logic of the underlying C library to ensure somewhat consistent behaviour among 
the same family of interfaces/libraries of a specific vendor.


Previous Comments:

[2012-03-06 01:39:12] johan...@php.net

I'm not sure I agree. For compression the developer should know what data to 
expect. Encryption should be configured alongside with host/user/password which 
usually happens in the application.
Having more places overriding each others makes it hard to figure out which 
settings arebeing used in the end.


[2011-11-22 03:02:50] spamik at yum dot pl

Description:

Using or not using mysql compression (or encryption) is a administrative 
decision, 
not decision that should be left for programmer as he usualy has no idea what 
is 
mysql configuration, what storage does it use and quite often this programmer 
just 
writes genuine aplications.
default for compression in mysql client (MYSQL_CLIENT_COMPRESS) should be 
settable 
in php.ini
http://pl2.php.net/manual/en/mysql.constants.php#mysql.client-flags

This would also to permanent connections but You made it into two diffrent 
commands so it would be more difficult.








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

Bug #61441 [Opn->Nab]: readlink returns operating system specific directory separators in result

2012-03-20 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=61441&edit=1

 ID: 61441
 Updated by: paj...@php.net
 Reported by:daveespionage at gmail dot com
 Summary:readlink returns operating system specific directory
 separators in result
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows 7 64 bit
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Expected behavior. All files operations working with paths to clean or resolve 
them returns the OS specific directory separator.


Previous Comments:

[2012-03-19 19:02:35] daveespionage at gmail dot com

I should have clarified in the description, $_SERVER['DOCUMENT_ROOT'] in this 
case 
is pointed to a directory symlink created with 'mklink /D', that has the alias 
'c:\sites\project' and resolves to 'c:\work\Project\wwwroot'


[2012-03-19 18:57:57] daveespionage at gmail dot com

Description:

readlink when called on a directory symlink in Windows 7 returns directory 
separators of '\', whereas seemingly most other filesystem functions return 
directory separators of '/' regardless of host operating system.

Test script:
---
';
echo 'Readlink: ' . readlink($_SERVER['DOCUMENT_ROOT']) . '';
?>

Expected result:

Docroot: C:/sites/project
Readlink: C:/work/Project/wwwroot

Actual result:
--
Docroot: C:/sites/project
Readlink: C:\work\Project\wwwroot






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

Bug #61443 [Fbk->Asn]: Since upgrade to PHP 5.4, we can't change zlib.output_compression on the fly.

2012-03-20 Thread debian at ange7 dot com 
Edit report at https://bugs.php.net/bug.php?id=61443&edit=1

 ID: 61443
 User updated by:debian at ange7 dot com
 Reported by:debian at ange7 dot com
 Summary:Since upgrade to PHP 5.4, we can't change
 zlib.output_compression on the  fly.
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:Zlib related
 Operating System:   Debian Sid
 PHP Version:5.4.0
 Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

code to reproduce :



Expected result:

end

Actual result:
--
Warning: ini_set(): Cannot enable zlib.output_compression - there has 
already been output in /home/alex/workspace/test/www/nouveauScript.php 
on line 3
end






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

[PHP-BUG] Bug #61450 [NEW]: oci8, open ldap not working

2012-03-20 Thread pratheeshrajan18 at gmail dot com 
From: 
Operating system: Linux
PHP version:  trunk-SVN-2012-03-20 (SVN)
Package:  *General Issues
Bug Type: Bug
Bug description:oci8, open ldap not working

Description:

ldap functionality is not working when i configure ldap and oci8 together.

I am getting "Out of memory" error while trying ldap. But, when i disabled
oci8, it worked well. Could some one help please..

My configuration looks like

'./configure' '--with-apxs2=/appl/apache3/bin/apxs'
'--with-mysql=/appl/mysql/' '--with-zlib' '--prefix=/appl/php5.2.9'
'--enable-sockets' '--with-ldap'
'--with-oci8=instantclient,/usr/lib/oracle/11.1/client64/lib/'
'--enable-mbstring' '--with-mysqli' '--with-xmlrpc' '--with-libxml-dir'
'--with-openssl' '--with-pcre-dir' '--with-pspell' '--enable-soap'
'--with-xmlrpc' '--with-curl' '--enable-exif' '--with-gd' 

I tried changing the order of ldap and oci8 in the config, that also didn't
work for me.

All thoughts welcome

Thanks,
Prats

Test script:
---
Sample code
---

ldap://ldap.example.com";;
$ldaprdn = "my user";
$ldappass = "my pass";

$ldap_conn = ldap_connect($ldapServer);

$ldapbind =ldap_bind($ldap_conn);


if($ldapbind) {
echo "success";
} else {

echo "LDAP-Errno: " . ldap_err2str(ldap_errno($ldap_conn)) . "\n";
echo "binding failed"; echo "";

Getting the ldap error no: 10.

Could any one have any idea ? 


Thanks in advance :)

Prats.



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

Bug #61450 [Opn]: oci8, open ldap not working

2012-03-20 Thread pratheeshrajan18 at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61450&edit=1

 ID: 61450
 User updated by:pratheeshrajan18 at gmail dot com
 Reported by:pratheeshrajan18 at gmail dot com
 Summary:oci8, open ldap not working
 Status: Open
 Type:   Bug
-Package:*General Issues
+Package:LDAP related
 Operating System:   Linux
 PHP Version:trunk-SVN-2012-03-20 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

changed to right package


Previous Comments:

[2012-03-20 10:10:18] pratheeshrajan18 at gmail dot com

Description:

ldap functionality is not working when i configure ldap and oci8 together.

I am getting "Out of memory" error while trying ldap. But, when i disabled 
oci8, it worked well. Could some one help please..

My configuration looks like

'./configure' '--with-apxs2=/appl/apache3/bin/apxs' '--with-mysql=/appl/mysql/' 
'--with-zlib' '--prefix=/appl/php5.2.9' '--enable-sockets' '--with-ldap' 
'--with-oci8=instantclient,/usr/lib/oracle/11.1/client64/lib/' 
'--enable-mbstring' '--with-mysqli' '--with-xmlrpc' '--with-libxml-dir' 
'--with-openssl' '--with-pcre-dir' '--with-pspell' '--enable-soap' 
'--with-xmlrpc' '--with-curl' '--enable-exif' '--with-gd' 

I tried changing the order of ldap and oci8 in the config, that also didn't 
work for me.

All thoughts welcome

Thanks,
Prats

Test script:
---
Sample code
---

ldap://ldap.example.com";;
$ldaprdn = "my user";
$ldappass = "my pass";

$ldap_conn = ldap_connect($ldapServer);

$ldapbind =ldap_bind($ldap_conn);


if($ldapbind) {
echo "success";
} else {

echo "LDAP-Errno: " . ldap_err2str(ldap_errno($ldap_conn)) . "\n";
echo "binding failed"; echo "";

Getting the ldap error no: 10.

Could any one have any idea ? 


Thanks in advance :)

Prats.








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

Req #60703 [Com]: support for reference cursors on pdo_oci

2012-03-20 Thread psrustik at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=60703&edit=1

 ID: 60703
 Comment by: psrustik at yandex dot ru
 Reported by:marcos dot ramirez dot aranda at gmail dot com
 Summary:support for reference cursors on pdo_oci
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

New php-5.3.10-cursor-support-for-pdo_oci.patch
also support with ZTS enabled configuration.


Previous Comments:

[2012-03-20 05:22:42] gureedo at gmail dot com

attatched patch does not work with ZTS enabled configuration.


[2012-01-10 19:55:18] marcos dot ramirez dot aranda at gmail dot com

Description:

PDO_OCI doesn't yet allow fetching ref cursors with oracle (or any other 
database). 

This patch adds support for fetching reference cursors on pdo_oci on both 
SELECT's as well CALL's to stored procedures (see the example below).


Test script:
---
$dbh = new PDO('oci:dbname=//localhost/XE', 'user', 'pass');
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);

$sql = "select cursor(select table_name, owner from all_tables where rownum <= 
1) as cursor from dual";
$sth = $dbh->prepare($sql);
$sth->execute();

$row = $sth->fetch(PDO::FETCH_ASSOC);
var_dump($row);
if (is_a($row['CURSOR'],'PDOStatement')) {
$sthc = $row['CURSOR'];
while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) {
  var_dump($rr);
}
 }
$sql = "begin OPEN :c FOR 'SELECT table_name FROM all_TABLES WHERE ROWNUM <= 
1'; END;";

$sthc = '';
$sth = $dbh->prepare($sql);
$sth->bindParam(":c", $sthc, PDO::PARAM_STMT|PDO::PARAM_INPUT_OUTPUT);

$sth->execute();
if ($sthc && is_a($sthc,'PDOStatement'))
  while ($rr = $sthc->fetch(PDO::FETCH_ASSOC)) {
var_dump($rr);
  }


Expected result:

array(1) {
  ["CURSOR"]=>
  object(PDOStatement)#3 (1) {
["queryString"]=>
NULL
  }
}
array(2) {
  ["TABLE_NAME"]=>
  string(5) "ICOL$"
  ["OWNER"]=>
  string(3) "SYS"
}
array(1) {
  ["TABLE_NAME"]=>
  string(5) "ICOL$"
}


Actual result:
--
PHP Warning:  PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932 
OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD


Warning: PDOStatement::fetch(): SQLSTATE[HY000]: General error: 932 
OCIStmtFetch: ORA-00932: inconsistent datatypes: expected CHAR got DTYCWD
bool(false)
PHP Warning:  PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008 
OCIStmtExecute: ORA-01008: not all variables bound

Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 1008 
OCIStmtExecute: ORA-01008: not all variables bound







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

Bug #61259 [Fbk]: "Segment Fault" executing a prepared statement with PDO-Mysql

2012-03-20 Thread mj 
Edit report at https://bugs.php.net/bug.php?id=61259&edit=1

 ID: 61259
 Updated by: m...@php.net
 Reported by:uabitesoj at gmail dot com
 Summary:"Segment Fault" executing a prepared statement with
 PDO-Mysql
 Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Linux 2.6.18 Centos 5.7
 PHP Version:5.3.10
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Can you please provide us with the exact schema definition of the MySQL table 
"user" that you referring to?


Previous Comments:

[2012-03-07 00:38:51] uabitesoj at gmail dot com

Thank you for your reply.

I recompiled my php with the suggested options for --with_mysqli and 
--with_pdo_mysql, and also I tried using the last snapshot. In all cases again 
I get a "Segment Fault" error.

The backtrace points to some problem in "mysqlnd_cset_escape_slashes" function.


[2012-03-05 00:29:24] johan...@php.net

Please try using this snapshot:

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

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

Your configure line is confusing.

--with-mysqli=mysqlnd \
--with-pdo-mysql \
--with-mysql-sock=/var/lib/mysql/mysqld.sock \

myslqi is using myslqnd whereas pdo_mysql is using libmysql from it's default 
location. Is that really your configuration? It is suggested to use mysqlnd for 
both.

--with-mysqli=mysqlnd \
--with-pdo-mysql=myslqnd

your backtrace indicates a conflict there (as it is referring to mysqlnd which 
shouldn't be used by PDO with the given configuration)

I couldn't reproduce with a pure myslqnd build. Please verify your 
configuration.


[2012-03-03 03:58:24] uabitesoj at gmail dot com

Description:

Now I'm using php-5.3.10.

Executing a prepared sql statemente with pdo-mysql produces a "Segmento Fault" 
error.

The configure line used to compile php is:
./configure \
--prefix=/usr/lib/php-5.3.10 \
--exec-prefix=/usr/lib/php-5.3.10 \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-config-file-path=/etc \
--enable-zip \
--enable-debug \
--with-curl=/usr/local \
--with-readline \
--enable-mbstring \
--with-mysqli=mysqlnd \
--with-pdo-mysql \
--with-mysql-sock=/var/lib/mysql/mysqld.sock \
--with-openssl \
--with-zlib \
--with-gd


Test script:
---
prepare($sql);
$stm->bindValue(1, 0);
$stm->bindValue(2, 'Name, Last Name, etc. etc.');
$stm->bindValue(3, 'log_name');
$stm->bindValue(4, SHA1('log_name', FALSE));
$stm->execute();
echo 'New user record saved in DB';
?>

Expected result:

Echoed 'New user record saved in DB' and a new record in "user" table.

Actual result:
--
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/php...done.
(gdb) run ExecutePrepared.php
Starting program: /usr/bin/php ExecutePrepared.php
warning: .dynamic section for "/lib/libc.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x08325563 in mysqlnd_cset_escape_slashes (cset=0x0, newstr=0x89db217 "p", 
escapestr=0x89dca6c "Name, Last name, etc., etc.",
escapestr_len=27) at 
/d/software/Php/php-5.3.10/ext/mysqlnd/mysqlnd_charset.c:718
718 if (cset->char_maxlen > 1 && (len = 
cset->mb_valid(escapestr, end))) {
(gdb) bt
#0  0x08325563 in mysqlnd_cset_escape_slashes (cset=0x0, newstr=0x89db217 "p", 
escapestr=0x89dca6c "Name, Last name, etc., etc.",
escapestr_len=27) at 
/d/software/Php/php-5.3.10/ext/mysqlnd/mysqlnd_charset.c:718
#1  0x081f6a55 in mysql_handle_quoter (dbh=0x89dc118, unquoted=0x89dca6c "Name, 
Last name, etc., etc.", unquotedlen=27,
quoted=0x89de1a0, quotedlen=0x89de19c, paramtype=PDO_PARAM_STR) at 
/d/software/Php/php-5.3.10/ext/pdo_mysql/mysql_driver.c:337
#2  0x081f5f89 in pdo_parse_params (stmt=0x89ddbec,
inquery=0x89ddd0c "INSERT INTO user (id, nombre, login, passwd) VALUES (?, 
?, ?, ?)", inquery_len=64, outquery=0x89ddc38,
outquery_len=0x89ddc3c) at 
/d/software/Php/php-5.3.10/ext/pdo/pdo_sql_parser.c:585
#3  0x081f2d59 in zim_PDOStatement_execute (ht=0, return_value=0x89ddeec, 
return_value_ptr=0x0, this_ptr=0x89dc1ec

Req #45569 [Com]: Suggestions for reflection API

2012-03-20 Thread kostia dot lukash at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=45569&edit=1

 ID: 45569
 Comment by: kostia dot lukash at gmail dot com
 Reported by:missingno at ifrance dot com
 Summary:Suggestions for reflection API
 Status: Open
 Type:   Feature/Change Request
 Package:Reflection related
 Operating System:   *
 PHP Version:5.2CVS-2008-07-20 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Any news?


Previous Comments:

[2008-07-20 11:40:26] missingno at ifrance dot com

Description:

I'm only submitting a suggestion made by Niels Jaeckel on the Reflection API 
which I think may be valuable.
See http://docs.php.net/reflection for the original post.


Niels suggested that a new object be created called ReflectionConstant.
ReflectionClass::getConstants() [and maybe also 
ReflectionExtension::getConstants()] should be changed to return an array of 
such objects.

This way, it would be possible to read DocComments for class constants.


Also, there is currently no way to retrieve the type hint of a given parameter 
(in ReflectionParameter). Maybe I should fill another bug report for this one ?

Reproduce code:
---
getConstants as $constant) {
  echo $constant->getName()." = ".$constant->getValue()." 
(".$contant->getDocComment().")\r\n";
}

echo "\r\n";

$method = new ReflectionMethod('MyString', '__construct');
foreach ($method->getParameters as $parameter) {
  echo "Type hint for ".$param->getName()." is ".$param->getTypeHint().".\r\n";
}

?>

Expected result:

I would expect something like the following to be echoed:

TYPE_ASCII = 1 (ASCII string)
TYPE_UNICODE = 2 (Unicode string)

Type hint for char is MyCharacter.
Type hint for type is .
// getTypeHint() could return NULL or FALSE if no type hint was given.

Actual result:
--
This is currently no way of retrieving the DocComment of a class constant. 
There is also no way of retrieving information about type hinting in methods' 
parameters.for






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

[PHP-BUG] Bug #61453 [NEW]: SplObjectStorage does not identify objects correctly

2012-03-20 Thread jhgundersen at gmail dot com 
From: 
Operating system: Linux
PHP version:  5.4.0
Package:  SPL related
Bug Type: Bug
Bug description:SplObjectStorage does not identify objects correctly

Description:

When I have a large collection of objects stored in a SplObjectStorage it
starts 
to behave strange. It says that an object already exists in the storage and

returns the stored data for another object. 

Test script:
---
$limit = 1000;
$objects = new SplObjectStorage;
for($i = 0; $i < $limit; $i++){
$object = new StdClass;

if(isset($objects[$object])){
die("this should never happen, but did after $i iteration");
}

$objects[$object] = 1;
}

echo "\nfinished\n";

Expected result:

The script should never enter the if condition and die, because the object
has 
not been added to the object storage yet

Actual result:
--
The scripts dies because of it finding an object in the storage that should
not 
have been there. This happens at random iteration, i'm guessing based on
memory 
usage or something.



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

Bug #61434 [Com]: zlib.output_compression not normal work in IIS7.5

2012-03-20 Thread a...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1

 ID: 61434
 Comment by: a...@php.net
 Reported by:info at ongod dot org
 Summary:zlib.output_compression not normal work in IIS7.5
 Status: Not a bug
 Type:   Bug
 Package:Zlib related
 Operating System:   windows2008R2x64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

As you can see, my tests was indeed with IIS7.5 as well, but PHP 5.4 from the 
trunk. The things happening on your server look like a configuration issue.

What you could do
* try another IIS instance, may be on your localhost
* try 5.4 trunk as well
* check that IIS doesn't drop any headers
* ask for help in the mailing lists


Previous Comments:

[2012-03-19 17:07:18] info at ongod dot org

it is Should be clean code for check. php5.4 not normal work.  but php5.3.10 
normal work in the same server.  who tell me why this ?

http://www.ongod.org/test/phpinfo.php

Web page compressed?No
Compression type?   none
Size, Markup (bytes)83,611
Size, Compressed (bytes)0
Compression %   0.0

php5.3.10
http://mail.ipv6china.com/phpinfo.php

Web page compressed?Yes
Compression type?   gzip
Size, Markup (bytes)87,124
Size, Compressed (bytes)13,730
Compression %   84.2

check from http://www.gidnetwork.com/tools/gzip-test.php


[2012-03-19 14:14:54] paj...@php.net

ok, not a bug but a support issue.

@info at ongod dot org

Please ask further support on the PHP general mailing list or any other support 
channel, thanks!


[2012-03-19 14:10:56] a...@php.net

I cannot reproduce the issue, tried with the latest php 5.4 and IIS7. IIS7 has 
compression turned off and the php.ini has both zlib.output_compression=on and 
zlib.output_compression_level=-1 set. The page is merely a phpinfo() page. Here 
the simple ping pong:

GET /i.php HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) 
Chrome/17.0.963.79 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 200 OK
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.4.1RC1-dev
Date: Mon, 19 Mar 2012 14:00:09 GMT
Content-Length: 6182

The output compression seems to work. 

@info at ongod dot org

Could you please try such a simple page scenario and post the request/response 
headers?


[2012-03-19 14:01:26] nacin at wordpress dot org

I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks 
like WP never has.


[2012-03-19 11:40:20] info at ongod dot org

Security reasons, I would also send an email to you.




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


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

Bug #61434 [Com]: zlib.output_compression not normal work in IIS7.5

2012-03-20 Thread a...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61434&edit=1

 ID: 61434
 Comment by: a...@php.net
 Reported by:info at ongod dot org
 Summary:zlib.output_compression not normal work in IIS7.5
 Status: Not a bug
 Type:   Bug
 Package:Zlib related
 Operating System:   windows2008R2x64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

btw just downloaded php-5.4.0-nts-Win32-VC9-x86 and tried it:

GET /i.php HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) 
Chrome/17.0.963.79 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 200 OK
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.4.0
Date: Tue, 20 Mar 2012 13:26:04 GMT
Content-Length: 9826

The output compression seems to be ok there as well.


Previous Comments:

[2012-03-20 12:56:24] a...@php.net

As you can see, my tests was indeed with IIS7.5 as well, but PHP 5.4 from the 
trunk. The things happening on your server look like a configuration issue.

What you could do
* try another IIS instance, may be on your localhost
* try 5.4 trunk as well
* check that IIS doesn't drop any headers
* ask for help in the mailing lists


[2012-03-19 17:07:18] info at ongod dot org

it is Should be clean code for check. php5.4 not normal work.  but php5.3.10 
normal work in the same server.  who tell me why this ?

http://www.ongod.org/test/phpinfo.php

Web page compressed?No
Compression type?   none
Size, Markup (bytes)83,611
Size, Compressed (bytes)0
Compression %   0.0

php5.3.10
http://mail.ipv6china.com/phpinfo.php

Web page compressed?Yes
Compression type?   gzip
Size, Markup (bytes)87,124
Size, Compressed (bytes)13,730
Compression %   84.2

check from http://www.gidnetwork.com/tools/gzip-test.php


[2012-03-19 14:14:54] paj...@php.net

ok, not a bug but a support issue.

@info at ongod dot org

Please ask further support on the PHP general mailing list or any other support 
channel, thanks!


[2012-03-19 14:10:56] a...@php.net

I cannot reproduce the issue, tried with the latest php 5.4 and IIS7. IIS7 has 
compression turned off and the php.ini has both zlib.output_compression=on and 
zlib.output_compression_level=-1 set. The page is merely a phpinfo() page. Here 
the simple ping pong:

GET /i.php HTTP/1.1
Host: localhost
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) 
Chrome/17.0.963.79 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 200 OK
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: PHP/5.4.1RC1-dev
Date: Mon, 19 Mar 2012 14:00:09 GMT
Content-Length: 6182

The output compression seems to work. 

@info at ongod dot org

Could you please try such a simple page scenario and post the request/response 
headers?


[2012-03-19 14:01:26] nacin at wordpress dot org

I can confirm that WordPress 3.3.1 does not set zlib.output_compression. Looks 
like WP never has.




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


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

[PHP-BUG] Bug #61454 [NEW]: ext\standard\tests\general_functions\bug49847.phpt fails

2012-03-20 Thread a...@php.net 
From: ab
Operating system: windows
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:ext\standard\tests\general_functions\bug49847.phpt fails

Description:

The test fails with the following diff out:

001+ 'more' is not recognized as an internal or external command,
002+ operable program or batch file.
003+ array(0) {
001- array(1) {
002-   [0]=>
003-   string(4098) "%s 1"

The patch supplied fixes the issue exchanging "more" with "type"

Expected result:

test pass

Actual result:
--
test fail

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

Bug #61454 [PATCH]: ext\standard\tests\general_functions\bug49847.phpt fails

2012-03-20 Thread a...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61454&edit=1

 ID: 61454
 Patch added by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\general_functions\bug49847.phpt
 fails
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

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


Previous Comments:

[2012-03-20 13:48:31] a...@php.net

Description:

The test fails with the following diff out:

001+ 'more' is not recognized as an internal or external command,
002+ operable program or batch file.
003+ array(0) {
001- array(1) {
002-   [0]=>
003-   string(4098) "%s 1"

The patch supplied fixes the issue exchanging "more" with "type"

Expected result:

test pass

Actual result:
--
test fail






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

[PHP-BUG] Req #61455 [NEW]: Warn when ini_set()'ing certain directives

2012-03-20 Thread brad at njoe dot com 
From: 
Operating system: N/A
PHP version:  5.3.10
Package:  PHP options/info functions
Bug Type: Feature/Change Request
Bug description:Warn when ini_set()'ing certain directives

Description:

If ini_set() is called to set any PHP directive whose 'Changeable'
attribute (e.g. 
as per man page http://php.net/ini.list) is not 'PHP_INI_USER' or
'PHP_INI_ALL', 
an error message could be generated to advise the developer that the
statement 
will have no effect. In other words, don't quietly allow directives to be
changed 
when they've already taken effect by the time the script is executed (thus

changing them via ini_set() won't ever do anything).

Test script:
---
 on line
3


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

Req #61455 [Opn]: Warn when ini_set()'ing certain directives

2012-03-20 Thread brad at njoe dot com 
Edit report at https://bugs.php.net/bug.php?id=61455&edit=1

 ID: 61455
 User updated by:brad at njoe dot com
 Reported by:brad at njoe dot com
 Summary:Warn when ini_set()'ing certain directives
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   N/A
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Errata #1 - Looks like PHP is intelligent enough to report the unchanged values 
for such directives when doing a phpinfo() (e.g. you can't ini_set() the 
'allow_url_fopen' directive and see the "Local Value" change on the phpinfo() 
page).

Thus, the "don't quietly allow directives to be changed" above should probably 
have been "don't quietly accept requests to change directives" or something of 
the 
sort.


Previous Comments:

[2012-03-20 13:56:55] brad at njoe dot com

Description:

If ini_set() is called to set any PHP directive whose 'Changeable' attribute 
(e.g. 
as per man page http://php.net/ini.list) is not 'PHP_INI_USER' or 
'PHP_INI_ALL', 
an error message could be generated to advise the developer that the statement 
will have no effect. In other words, don't quietly allow directives to be 
changed 
when they've already taken effect by the time the script is executed (thus 
changing them via ini_set() won't ever do anything).

Test script:
---
 on line 3







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

Req #61439 [Com]: POST and other methods input data handling

2012-03-20 Thread martin dot koranda at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61439&edit=1

 ID: 61439
 Comment by: martin dot koranda at gmail dot com
 Reported by:martin dot koranda at gmail dot com
 Summary:POST and other methods input data handling
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

mike:   yes that's better, parse it regarding on the request content type. it 
should be also good if it could automatically parse json or xml input, but main 
is 
the multipart.
do you think you can push your proposal to some of the next builds?


Previous Comments:

[2012-03-20 09:01:37] m...@php.net

I second that. Actually I've sitting an unfinished proposal in my Inbox' Drafts 
which addresses this issue.

BUT, I'm not thinking about php.ini, but SAPI code shouldn't care about the 
request method, but the request body's content type. And there should be an API 
to register content-type handlers.


[2012-03-19 17:36:38] martin dot koranda at gmail dot com

Description:

when sending multipart/form-data via a POST method, PHP internally parses all 
variables into $_POST and files into $_FILES. but the parsing is not done with 
any 
other method (PUT,PATCH,PROPFIND ..)

additionally, sending POST with multipart/form-data makes php://input 
unavailable.

so there is no universal parsing solution which covers all methods.

there should be a setting option (php.ini) where i can determine which 
particular 
methods i want the internal parser run for (eg.  "parse_input_methods = 
POST,PUT,PATCH")

and/or there should be an option for disabling that internal parser completely.







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

[PHP-BUG] Bug #61456 [NEW]: iconv set encoding bug

2012-03-20 Thread tamate at hotmail dot com 
From: 
Operating system: Linux
PHP version:  5.3.10
Package:  Testing related
Bug Type: Bug
Bug description:iconv set encoding bug

Description:

---
>From manual page: http://php.net/manual/en/function.iconv-set-encoding.php
---


Test script:
---


Expected result:

Running successfully

Actual result:
--
If you try the above one, you will get this error - 

Parse error: syntax error, unexpected T_STRING in directory/blah/directory
on line 3

Pointed at
iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');

even if you try iconv_set_encoding('output_encoding','ISO-8859-1');

You will see that you will still get an error.
I am not sure why this is happening, I am running on linux php 5.3

Or is there something wrong with my coding?

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

Bug #61456 [Opn]: iconv set encoding bug

2012-03-20 Thread tamate at hotmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61456&edit=1

 ID: 61456
 User updated by:tamate at hotmail dot com
 Reported by:tamate at hotmail dot com
 Summary:iconv set encoding bug
 Status: Open
 Type:   Bug
 Package:Testing related
 Operating System:   Linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Line 5*

Live example - http://giantcrabby.com/test/test.php


Previous Comments:

[2012-03-20 17:02:07] tamate at hotmail dot com

Description:

---
>From manual page: http://php.net/manual/en/function.iconv-set-encoding.php
---


Test script:
---


Expected result:

Running successfully

Actual result:
--
If you try the above one, you will get this error - 

Parse error: syntax error, unexpected T_STRING in directory/blah/directory on 
line 3

Pointed at iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');

even if you try iconv_set_encoding('output_encoding','ISO-8859-1');

You will see that you will still get an error.
I am not sure why this is happening, I am running on linux php 5.3

Or is there something wrong with my coding?






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

Bug #61456 [Opn]: iconv set encoding bug

2012-03-20 Thread tamate at hotmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61456&edit=1

 ID: 61456
 User updated by:tamate at hotmail dot com
 Reported by:tamate at hotmail dot com
 Summary:iconv set encoding bug
 Status: Open
 Type:   Bug
-Package:Testing related
+Package:ICONV related
 Operating System:   Linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

ICONV related*


Previous Comments:

[2012-03-20 17:08:01] tamate at hotmail dot com

Line 5*

Live example - http://giantcrabby.com/test/test.php


[2012-03-20 17:02:07] tamate at hotmail dot com

Description:

---
>From manual page: http://php.net/manual/en/function.iconv-set-encoding.php
---


Test script:
---


Expected result:

Running successfully

Actual result:
--
If you try the above one, you will get this error - 

Parse error: syntax error, unexpected T_STRING in directory/blah/directory on 
line 3

Pointed at iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');

even if you try iconv_set_encoding('output_encoding','ISO-8859-1');

You will see that you will still get an error.
I am not sure why this is happening, I am running on linux php 5.3

Or is there something wrong with my coding?






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

Bug #61456 [Opn->Nab]: iconv set encoding bug

2012-03-20 Thread philip 
Edit report at https://bugs.php.net/bug.php?id=61456&edit=1

 ID: 61456
 Updated by: phi...@php.net
 Reported by:tamate at hotmail dot com
 Summary:iconv set encoding bug
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

You're missing a ; on line #4.


Previous Comments:

[2012-03-20 17:10:36] tamate at hotmail dot com

ICONV related*


[2012-03-20 17:08:01] tamate at hotmail dot com

Line 5*

Live example - http://giantcrabby.com/test/test.php


[2012-03-20 17:02:07] tamate at hotmail dot com

Description:

---
>From manual page: http://php.net/manual/en/function.iconv-set-encoding.php
---


Test script:
---


Expected result:

Running successfully

Actual result:
--
If you try the above one, you will get this error - 

Parse error: syntax error, unexpected T_STRING in directory/blah/directory on 
line 3

Pointed at iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');

even if you try iconv_set_encoding('output_encoding','ISO-8859-1');

You will see that you will still get an error.
I am not sure why this is happening, I am running on linux php 5.3

Or is there something wrong with my coding?






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

Req #45906 [Com]: Cannot use square brackets on a function

2012-03-20 Thread php dot net at doppy dot nl 
Edit report at https://bugs.php.net/bug.php?id=45906&edit=1

 ID: 45906
 Comment by: php dot net at doppy dot nl
 Reported by:david dot c dot cook+php at gmail dot com
 Summary:Cannot use square brackets on a function
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

This is implemented in PHP 5.4.
This request can be closed.


Previous Comments:

[2008-08-25 02:35:53] david dot c dot cook+php at gmail dot com

Description:

Cannot use square brackets to directly reference array elements in the returned 
value of a function. As a flexible language that can do pretty much anything, 
it seems logical to be able to achieve this on one line, without having to 
first assign the return value to a temporary variable.

Reproduce code:
---
function test()
{ 
   return array('a', 'b'); 
}

//desired
echo test()[0];

//workaround
//$temp = test();
//echo $temp[0];

Expected result:

a

Actual result:
--
Parse error: syntax error, unexpected '['






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

Bug #44294 [Com]: Undefined symbols with libxml2

2012-03-20 Thread jmlane at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=44294&edit=1

 ID: 44294
 Comment by: jmlane at gmail dot com
 Reported by:danval at gmail dot com
 Summary:Undefined symbols with libxml2
 Status: No Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac 10.5 Leopard Client
 PHP Version:5.*, 6CVS (2009-07-09)
 Assigned To:fb-req-jani
 Block user comment: N
 Private report: N

 New Comment:

Issue still exists in 5.x trunk from SVN.

The solution is simple: in the Makefile, on the line where 
"libs/libphp$(PHP_MAJOR_VERSION).bundle:" appears, the $(MH_BUNDLE_FLAGS) 
variable should be called after "$(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) 
$(EXTRA_LDFLAGS)" so that the hard-coded "/usr/lib" search path is searched 
after any user-provided search paths given during configure.

For example, the Makefile currently contains this passage:

"MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/sbin/httpd -L/usr/lib -L/usr/lib 
-laprutil-1 -lsqlite3 -lexpat -liconv -L/usr/lib -lapr-1 -lpthread"

...which sets library search paths as '/usr/lib'.

Further below:

"libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
$(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) 
$(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) 
$(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ 
libs/libphp$(PHP_MAJOR_VERSION).so"

...demonstrates that the '-L/usr/lib' from $MH_BUNDLE_FLAGS is given priority 
and will be searched before the '-L/custom/paths' contained in the variables 
immediately following it. This is likely not the intended behaviour, since it 
circumvents the user's intentions when passing library search paths to the 
configure script.

What should be found in the Makefile—which will resolve this issue—is the 
following:

"libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS)
$(CC) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) $(EXTRA_LDFLAGS) 
$(MH_BUNDLE_FLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) 
$(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@ 
libs/libphp$(PHP_MAJOR_VERSION).so"

Can anyone with autotools and PHP build process familiarity comment on any 
possible repercussions from this minor and logical change?


Previous Comments:

[2009-07-18 23:20:06] rdohms at gmail dot com

Jani.

Adding /lib was the only way i got it working.. otherwise it skipped those dirs 
and kep hamerring /usr/lib which is the next in line, like here:

cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd  -L/usr/lib 
-L/usr/lib -laprutil-1...

What i have been doing to compile succesfully is altering to this

cc -bundle -bundle_loader /Applications/Server/Apache2/bin/httpd -L/opt/xml/lib 
-L/opt/local/lib -L/usr/lib -L/usr/lib -laprutil-1...

This was gwyne's suggestion and it works great.

After I enabled OpenSSL i got evem more of these, hence the /opt/local/lib i 
also placed there.

As for versions, i have reproduced these today on:
PHP_5_3, PHP_5_2 and trunk, straight from SVN


I'm rdohms on php.pecl if you want to chat about this


[2009-07-17 01:00:00] php-bugs at lists dot php dot net

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


[2009-07-09 20:43:44] j...@php.net

And if you change the version, add a note about it. Now there's no way 
to know what version you reported this with, what version it works 
with..etc.


[2009-07-09 20:41:49] j...@php.net

Remove the /lib from those paths. "rdohms at gmail dot com":  Where did 
you get the idea it's okay to pass that anywhere?!


[2009-06-22 13:49:51] rdohms at gmail dot com

actualy sorry.

I had --with-libxml-dir declared.
Tried running it with --enable-xmlreader-/opt/xml/lib, just like the above 
setting and it broke on the same place as before.




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


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

Req #40248 [Com]: Undefined members with combined operators produce no warning

2012-03-20 Thread php dot net at doppy dot nl 
Edit report at https://bugs.php.net/bug.php?id=40248&edit=1

 ID: 40248
 Comment by: php dot net at doppy dot nl
 Reported by:jontsa at amigaone dot cc
 Summary:Undefined members with combined operators produce no
 warning
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Solaris
 PHP Version:5.2.0
 Block user comment: N
 Private report: N

 New Comment:

Can still reproduce this.


PHP 5.3.10-1ubuntu2 with Suhosin-Patch (cli) (built: Mar  5 2012 18:27:21) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies



Recommend using this reproduce code:

a+=5;

$b=new stdClass;
$b->a=$b->a + 5;


Expected result:

PHP Notice:  Undefined variable: a in /test.php on line 3
PHP Notice:  Undefined property: stdClass::$a in /test.php on line 6
PHP Notice:  Undefined property: stdClass::$a in /test.php on line 9


Actual result:

PHP Notice:  Undefined variable: a in /test.php on line 3
PHP Notice:  Undefined property: stdClass::$a in /test.php on line 9



Previous Comments:

[2007-01-26 10:12:51] jontsa at amigaone dot cc

Description:

When using a combined operator like += or ++ on an undefined class member, it 
does not produce "undefined property" notice as expected. Tested with all 
errors enabled.

Reproduce code:
---
$a+=5;
$b=new stdClass;
$b->a+=5;


Expected result:

Notice: Undefined variable: a
Notice: Undefined property: stdClass::$a

Actual result:
--
Notice: Undefined variable: a






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

[PHP-BUG] Bug #61458 [NEW]: unixtojd() undefined

2012-03-20 Thread lsiden at gmail dot com 
From: 
Operating system: SunOS 5.10
PHP version:  5.3.10
Package:  Date/time related
Bug Type: Bug
Bug description:unixtojd() undefined

Description:

Since upgrading from PHP 5.2.9 to 5.3.10, PHP is throwing the error:

... PHP Fatal error:  Call to undefined function unixtojd() in
.../unixtojd.php on 
line 5

Checking phpinfo(), I can see that the calendar lib is enabled:
'--enable-calendar=shared' 

Searching on Google for posts since the first release of PHP 5.3 (June 30,
2009) 
did not reveal much more: http://goo.gl/2YbWj

If anyone has an answer, please notify me 
Thank you!

Test script:
---





Expected result:

1332277193
2456007
showdiff(1.1.2012 00:00:00 GMT, 15.1.2012 00:00:00 GMT)
14
showdiff(1.3.2012 00:00:00 GMT, 15.3.2012 00:00:00 GMT)
14

Actual result:
--
... PHP Fatal error:  Call to undefined function unixtojd() in
.../unixtojd.php on 
line 5


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

Bug #61441 [Nab]: readlink returns operating system specific directory separators in result

2012-03-20 Thread daveespionage at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61441&edit=1

 ID: 61441
 User updated by:daveespionage at gmail dot com
 Reported by:daveespionage at gmail dot com
 Summary:readlink returns operating system specific directory
 separators in result
 Status: Not a bug
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows 7 64 bit
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

@pajoye: Is this in the PHP documentation anywhere?  I cannot find it in 
http://php.net/manual/en/function.readlink.php or the parent 
http://www.php.net/manual/en/ref.filesystem.php

Should I file a missing documentation bug?

Thanks!


Previous Comments:

[2012-03-20 10:06:15] paj...@php.net

Expected behavior. All files operations working with paths to clean or resolve 
them returns the OS specific directory separator.


[2012-03-19 19:02:35] daveespionage at gmail dot com

I should have clarified in the description, $_SERVER['DOCUMENT_ROOT'] in this 
case 
is pointed to a directory symlink created with 'mklink /D', that has the alias 
'c:\sites\project' and resolves to 'c:\work\Project\wwwroot'


[2012-03-19 18:57:57] daveespionage at gmail dot com

Description:

readlink when called on a directory symlink in Windows 7 returns directory 
separators of '\', whereas seemingly most other filesystem functions return 
directory separators of '/' regardless of host operating system.

Test script:
---
';
echo 'Readlink: ' . readlink($_SERVER['DOCUMENT_ROOT']) . '';
?>

Expected result:

Docroot: C:/sites/project
Readlink: C:/work/Project/wwwroot

Actual result:
--
Docroot: C:/sites/project
Readlink: C:\work\Project\wwwroot






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

Bug #51225 [Com]: cannot define a class with the same name as an interface

2012-03-20 Thread LaKing at D250 dot hu 
Edit report at https://bugs.php.net/bug.php?id=51225&edit=1

 ID: 51225
 Comment by: LaKing at D250 dot hu
 Reported by:tony at marston-home dot demon dot co dot uk
 Summary:cannot define a class with the same name as an
 interface
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Windows XP
 PHP Version:5.2.13
 Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

The language-developers have two options. Either a clearer error message as a 
quick-fix, or allowing interfaces and classes with the same name, with the 
necessary underlying updates properly implemented in the language. That would 
be the elegant, and logical way.


Previous Comments:

[2010-09-23 08:03:40] i at walkinraven dot name

I think you the fact of class and interface sharing a same namespace should be 
clearly written into the manual!

And the better way, the two should not share a same namespace at all.

It waste me some much time to check my project.


[2010-08-05 23:38:58] bobalicious dot bob at gmail dot com

In my opinion, in order to be valid the code snippet should read:

if (!class_exists('foobar') && !interface_exists('foobar') ) {
class foobar{}
}

The error message on attempting to declare a class with the same name as an 
interface should respond:
Cannot declare class as an interface exists with that name
The reverse message should also be possible.

It does not make sense to allow an interface and a class to have the same name 
(type hinting is a great example why not), and 'class_exists' should only refer 
to classes (the clue's in the name).

The confusion is merely down to an inaccurate error message.

Note: There's a reason it's not uncommon for people to prefix interfaces with 
an 
'i'


[2010-03-08 10:35:06] tony at marston-home dot demon dot co dot uk

I disagree. class_exists() SHOULD check if that name has already been declared 
as an interface otherwise you get the following situation:

if (!class_exists('foobar') {  // returns false
class foobar{} // fails because interface exists
}

On the one hand it is saying "a class with the name 'foobar' does not exist" 
which is immediately followed by "you cannot create a class with the name 
'foobar' as it already exists". That is not logical to me.


[2010-03-08 00:55:52] johan...@php.net

I think the error message ("Cannot redeclare class") should be clearer about 
classes and interfaces sharing the same namespace, which is needed as type 
hints would be conflicting otherwise, but class_exists (by default) should only 
check classes in my opinion. Any change should consider that there's also 
interface_exists() and they should be consistent.


[2010-03-08 00:28:39] der...@php.net

Yes, I agree.




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


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

[PHP-BUG] Bug #61459 [NEW]: popen_close_error-win32 can't run sort.exe

2012-03-20 Thread mattfic...@php.net 
From: mattficken
Operating system: Windows
PHP version:  5.3.10
Package:  Testing related
Bug Type: Bug
Bug description:popen_close_error-win32 can't run sort.exe

Description:

popen("sort", "w") fails if variables_order="GPCS"
this is set in the default INI file. it doesn't seem to be changeable in
the --INI-- section of PHPT test. also, doing: ini_set('variables_order',
''); doesn't work!

the only solutions are to either put the absolute path here, or remove
variables_order= from PHP.ini (setting it in run-test's default INI will
fail too).

since we can't depend on PHP.ini being set a certain way, have to put the
absolute path here.

Test fails

Expected result:

test pass

Actual result:
--
test fail

004+ 'sort' is not recognized as an internal or external command,
005+ operable program or batch file.
004- aaa
005- ddd
006- ggg
007- sss



Expected result:

Test pass


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

Bug #61459 [PATCH]: popen_close_error-win32 can't run sort.exe

2012-03-20 Thread mattfic...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61459&edit=1

 ID: 61459
 Patch added by: mattfic...@php.net
 Reported by:mattfic...@php.net
 Summary:popen_close_error-win32 can't run sort.exe
 Status: Open
 Type:   Bug
 Package:Testing related
 Operating System:   Windows
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: popen_close_error-win32
Revision:   1332283902
URL:
https://bugs.php.net/patch-display.php?bug=61459&patch=popen_close_error-win32&revision=1332283902


Previous Comments:

[2012-03-20 22:51:35] mattfic...@php.net

Description:

popen("sort", "w") fails if variables_order="GPCS"
this is set in the default INI file. it doesn't seem to be changeable in the 
--INI-- section of PHPT test. also, doing: ini_set('variables_order', ''); 
doesn't work!

the only solutions are to either put the absolute path here, or remove 
variables_order= from PHP.ini (setting it in run-test's default INI will fail 
too).

since we can't depend on PHP.ini being set a certain way, have to put the 
absolute path here.

Test fails

Expected result:

test pass

Actual result:
--
test fail

004+ 'sort' is not recognized as an internal or external command,
005+ operable program or batch file.
004- aaa
005- ddd
006- ggg
007- sss



Expected result:

Test pass







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

[PHP-BUG] Bug #61460 [NEW]: popen_close_error-win32 expected output is wrong

2012-03-20 Thread mattfic...@php.net 
From: mattficken
Operating system: Windows
PHP version:  5.3.10
Package:  Testing related
Bug Type: Bug
Bug description:popen_close_error-win32 expected output is wrong

Description:

Warning messages have changed since test written. Expected output is
incorrect. See patch.

Expected result:

test pass

Actual result:
--
test fail



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

Bug #61460 [Com]: popen_close_error-win32 expected output is wrong

2012-03-20 Thread mattfic...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61460&edit=1

 ID: 61460
 Comment by: mattfic...@php.net
 Reported by:mattfic...@php.net
 Summary:popen_close_error-win32 expected output is wrong
 Status: Open
 Type:   Bug
 Package:Testing related
 Operating System:   Windows
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This patch fixes it:

20c20
< echo "*** Testing for error conditions ***\n";
---
> echo "*** Testing for error conditions ***".PHP_EOL;
22a23
> 
23a25
> 
29c31
< echo "\n--- Done ---";
---
> echo PHP_EOL.PHP_EOL."--- Done ---";
44,46c46,48
< resource(%d) of type (stream)
< 'abc.txt' is not recognized as an internal or external command,
< operable program or batch file.
---
> 
> Warning: popen(abc.txt,rw): Invalid argument in %s on line %d
> bool(false)
57c59,61
< --- Done ---
---
> 
> --- Done ---'abc.txt' is not recognized as an internal or external command,
> operable program or batch file.


Previous Comments:

[2012-03-20 22:54:08] mattfic...@php.net

Description:

Warning messages have changed since test written. Expected output is incorrect. 
See patch.

Expected result:

test pass

Actual result:
--
test fail








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

Bug #61458 [Opn->Nab]: unixtojd() undefined

2012-03-20 Thread rasmus 
Edit report at https://bugs.php.net/bug.php?id=61458&edit=1

 ID: 61458
 Updated by: ras...@php.net
 Reported by:lsiden at gmail dot com
 Summary:unixtojd() undefined
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Date/time related
 Operating System:   SunOS 5.10
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

--enable-calendar=shared doesn't mean the extension is enabled. It means it was 
built shared. Without an extension=calendar.so in your php.ini it won't be 
loaded.


Previous Comments:

[2012-03-20 21:08:00] lsiden at gmail dot com

Description:

Since upgrading from PHP 5.2.9 to 5.3.10, PHP is throwing the error:

... PHP Fatal error:  Call to undefined function unixtojd() in .../unixtojd.php 
on 
line 5

Checking phpinfo(), I can see that the calendar lib is enabled:
'--enable-calendar=shared' 

Searching on Google for posts since the first release of PHP 5.3 (June 30, 
2009) 
did not reveal much more: http://goo.gl/2YbWj

If anyone has an answer, please notify me 
Thank you!

Test script:
---





Expected result:

1332277193
2456007
showdiff(1.1.2012 00:00:00 GMT, 15.1.2012 00:00:00 GMT)
14
showdiff(1.3.2012 00:00:00 GMT, 15.3.2012 00:00:00 GMT)
14

Actual result:
--
... PHP Fatal error:  Call to undefined function unixtojd() in .../unixtojd.php 
on 
line 5







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

Bug #61454 [Com]: ext\standard\tests\general_functions\bug49847.phpt fails

2012-03-20 Thread mattfic...@php.net 
Edit report at https://bugs.php.net/bug.php?id=61454&edit=1

 ID: 61454
 Comment by: mattfic...@php.net
 Reported by:a...@php.net
 Summary:ext\standard\tests\general_functions\bug49847.phpt
 fails
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:Irrelevant
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

This patch fixes the bug for me on 5_3-r324324


Previous Comments:

[2012-03-20 13:49:11] a...@php.net

The following patch has been added/updated:

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


[2012-03-20 13:48:31] a...@php.net

Description:

The test fails with the following diff out:

001+ 'more' is not recognized as an internal or external command,
002+ operable program or batch file.
003+ array(0) {
001- array(1) {
002-   [0]=>
003-   string(4098) "%s 1"

The patch supplied fixes the issue exchanging "more" with "type"

Expected result:

test pass

Actual result:
--
test fail






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

Req #45906 [Opn->Csd]: Cannot use square brackets on a function

2012-03-20 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=45906&edit=1

 ID: 45906
 Updated by: ahar...@php.net
 Reported by:david dot c dot cook+php at gmail dot com
 Summary:Cannot use square brackets on a function
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 PHP Version:5.2.6
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

Good catch; thanks.


Previous Comments:

[2012-03-20 19:18:20] php dot net at doppy dot nl

This is implemented in PHP 5.4.
This request can be closed.


[2008-08-25 02:35:53] david dot c dot cook+php at gmail dot com

Description:

Cannot use square brackets to directly reference array elements in the returned 
value of a function. As a flexible language that can do pretty much anything, 
it seems logical to be able to achieve this on one line, without having to 
first assign the return value to a temporary variable.

Reproduce code:
---
function test()
{ 
   return array('a', 'b'); 
}

//desired
echo test()[0];

//workaround
//$temp = test();
//echo $temp[0];

Expected result:

a

Actual result:
--
Parse error: syntax error, unexpected '['






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

[PHP-BUG] Bug #61461 [NEW]: Large HTTP request Content-Length header values result in failed malloc() call

2012-03-20 Thread contact at kaankivilcim dot com 
From: 
Operating system: All
PHP version:  5.4.0
Package:  Built-in web server
Bug Type: Bug
Bug description:Large HTTP request Content-Length header values result in 
failed malloc() call

Description:

A denial of service condition can be triggered by HTTP requests that are
sent to the built-in PHP web server with a large Content-Length header
value.

The value of the Content-Length header is passed directly to a pemalloc()
call in sapi/cli/php_cli_server.c on line 1538. The inline function defined
within Zend/zend_alloc.h for malloc() will fail, and will terminate the
process with the error message "Out of memory".

1534static int php_cli_server_client_read_request_on_body(php_http_parser
*parser, const char *at, size_t length)
1535{
1536php_cli_server_client *client = parser->data;
1537if (!client->request.content) {
1538client->request.content = pemalloc(parser->content_length, 1);
1539client->request.content_len = 0;
1540}
1541memmove(client->request.content + client->request.content_len, at,
length);
1542client->request.content_len += length;
1543return 0;
1544}

Setting a value (e.g. 2^31 - 10) for the Content-Length header close to the
upper limit of an int for the platform (e.g. 32-bit) in use will trigger
the condition.

Test script:
---
An example HTTP request that will trigger the bug is shown below.

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 2147483648

A=B

Expected result:

The expected output would be a meaningful error message.

Invalid request (Requested Content-Length is larger the allowed limit of
XYZ)

Actual result:
--
The output observed for the PHP process is shown below.

PHP 5.4.0 Development Server started at Tue Mar 20 19:41:45 2012
Listening on 127.0.0.1:80
Document root is /tmp
Press Ctrl-C to quit.
Out of memory

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

Bug #61461 [Opn->Csd]: Large HTTP request Content-Length header values result in failed malloc() call

2012-03-20 Thread iliaa 
Edit report at https://bugs.php.net/bug.php?id=61461&edit=1

 ID: 61461
 Updated by: il...@php.net
 Reported by:contact at kaankivilcim dot com
 Summary:Large HTTP request Content-Length header values
 result in failed malloc() call
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 Operating System:   All
 PHP Version:5.4.0
-Assigned To:
+Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-03-21 00:53:18] contact at kaankivilcim dot com

Description:

A denial of service condition can be triggered by HTTP requests that are sent 
to the built-in PHP web server with a large Content-Length header value.

The value of the Content-Length header is passed directly to a pemalloc() call 
in sapi/cli/php_cli_server.c on line 1538. The inline function defined within 
Zend/zend_alloc.h for malloc() will fail, and will terminate the process with 
the error message "Out of memory".

1534static int php_cli_server_client_read_request_on_body(php_http_parser 
*parser, const char *at, size_t length)
1535{
1536php_cli_server_client *client = parser->data;
1537if (!client->request.content) {
1538client->request.content = pemalloc(parser->content_length, 1);
1539client->request.content_len = 0;
1540}
1541memmove(client->request.content + client->request.content_len, at, 
length);
1542client->request.content_len += length;
1543return 0;
1544}

Setting a value (e.g. 2^31 - 10) for the Content-Length header close to the 
upper limit of an int for the platform (e.g. 32-bit) in use will trigger the 
condition.

Test script:
---
An example HTTP request that will trigger the bug is shown below.

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 2147483648

A=B

Expected result:

The expected output would be a meaningful error message.

Invalid request (Requested Content-Length is larger the allowed limit of XYZ)

Actual result:
--
The output observed for the PHP process is shown below.

PHP 5.4.0 Development Server started at Tue Mar 20 19:41:45 2012
Listening on 127.0.0.1:80
Document root is /tmp
Press Ctrl-C to quit.
Out of memory






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

Bug #61459 [Opn->Asn]: popen_close_basic-win32 can't run sort.exe

2012-03-20 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=61459&edit=1

 ID: 61459
 Updated by: paj...@php.net
 Reported by:mattfic...@php.net
 Summary:popen_close_basic-win32 can't run sort.exe
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Windows
 PHP Version:5.3.10
-Assigned To:
+Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

Hi,

Please add a SKIPIF section testing if sort.exe exists in this path. 

Thanks!


Previous Comments:

[2012-03-20 22:51:43] mattfic...@php.net

The following patch has been added/updated:

Patch Name: popen_close_error-win32
Revision:   1332283902
URL:
https://bugs.php.net/patch-display.php?bug=61459&patch=popen_close_error-win32&revision=1332283902


[2012-03-20 22:51:35] mattfic...@php.net

Description:

popen("sort", "w") fails if variables_order="GPCS"
this is set in the default INI file. it doesn't seem to be changeable in the 
--INI-- section of PHPT test. also, doing: ini_set('variables_order', ''); 
doesn't work!

the only solutions are to either put the absolute path here, or remove 
variables_order= from PHP.ini (setting it in run-test's default INI will fail 
too).

since we can't depend on PHP.ini being set a certain way, have to put the 
absolute path here.

Test fails

Expected result:

test pass

Actual result:
--
test fail

004+ 'sort' is not recognized as an internal or external command,
005+ operable program or batch file.
004- aaa
005- ddd
006- ggg
007- sss



Expected result:

Test pass







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

Bug #54374 [Csd]: Insufficient validating of upload name leading to corrupted $_FILES indices

2012-03-20 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=54374&edit=1

 ID: 54374
 Updated by: paj...@php.net
 Reported by:lekensteyn at gmail dot com
 Summary:Insufficient validating of upload name leading to
 corrupted $_FILES indices
 Status: Closed
 Type:   Bug
 Package:Variables related
 Operating System:   All
 PHP Version:5.3.8
-Assigned To:stas
+Assigned To:pajoye
 Block user comment: N
 Private report: N
 CVE-ID: 2012-1172

 New Comment:

Merged into 5.3


Previous Comments:

[2012-01-01 23:55:17] s...@php.net

This bug has been fixed in SVN.

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

 For Windows:

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




[2012-01-01 23:53:58] s...@php.net

Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=321664
Log: fix bug #54374, bug #55500 - filter file names better, no dangling [s


[2011-11-18 10:40:22] lekensteyn at gmail dot com

This is not a documentation bug and still exists in PHP 5.3.8.


[2011-03-24 20:07:31] lekensteyn at gmail dot com

Description:

SAPI: Apache 2 module (it should apply to other SAPI's which accepts uploads as 
well)
OS: Debian 6 (it should apply to other OSes as well)
PHP: 5.3.6 (from source, test compile: ./configure --prefix=/tmp/diebug 
--disable-all --with-apxs2=/tmp/diebug/bin/apxs --disable-cli)

Upload names with brackets ([ and ]) are created for creating arrays of files.
Any array index or variable name containing a bracket should be invalid.

The current implementation only checks whether more closing brackets are 
detected than opening brackets.
Related files
http://lxr.php.net/opengrok/xref/PHP_5_3/main/rfc1867.c#990
http://lxr.php.net/opengrok/xref/PHP_TRUNK/main/rfc1867.c#920

Relevant code:
--snip--
/* New Rule: never repair potential malicious user input */
if (!skip_upload) {
long c = 0;
tmp = param;

while (*tmp) {
if (*tmp == '[') {
c++;
} else if (*tmp == ']') {
c--;
if (tmp[1] && tmp[1] != '[') {
skip_upload = 1;
break;
}
}
if (c < 0) {
skip_upload = 1;
break;
}
tmp++;
}
}
--snip--

So names like `test]` and `test[]]` are invalid, but names like `test[` pass 
this test.

Now it gets worse, the upload is accepted and without checking the name, and 
registered:
--snip--
if (is_arr_upload) {
snprintf(lbuf, llen, "%s[name][%s]", abuf, array_index);
} else {
snprintf(lbuf, llen, "%s[name]", param);
}
if (s && s > filename) {
register_http_post_files_variable(lbuf, s+1, http_post_files, 0 
TSRMLS_CC);
} else {
register_http_post_files_variable(lbuf, filename, http_post_files, 0 
TSRMLS_CC);
}
--snip--

register_http_post_files_variable calls safe_php_register_variable:
--snip
if (override_protection || !is_protected_variable(var TSRMLS_CC)) {
php_register_variable_safe(var, strval, val_len, track_vars_array 
TSRMLS_CC);
}
--snip--

override_protection is false, the only condition that checks whether the 
variable name is accepted is the is_protected_variable call, passing the upload 
name. The variable name is normalized using normalize_protected_variable() and 
then checked for existence in the $_FILES array.
The normalization function normalize_protected_variable checks whether a 
closing bracket is found, and otherwise uses the following string as index:
--snip--
indexend = strchr(index, ']');
indexend = indexend ? indexend + 1 : index + strlen(index);

--snip--
This implies that the index name can contain a opening bracket as well, which 
will be accepted and passed directly to php_register_variable_safe.

The suggested patch adds a check to ensure that the leftover open brackets is 
always zero. If not, it simply drops the upload (better safe than sorry).

Test script:
---
%s', htmlspecialchars(print_r($_FILES, true)));
}
?>






Expected result:

I expected to see "OK expected result" and an empty array dump because the name 
is invalid.

Actual result:
--
The test script produces "Unexpected result".
The upload is accepted but the $_FILES array is corrupt