[PHP-BUG] Req #61298 [NEW]: Add an short alias DS for DIRECTORY_SEPARATOR

[cornelius dot howl at gmail dot com]

From: 
Operating system: 
PHP version:  5.4.0
Package:  *Directory/Filesystem functions
Bug Type: Feature/Change Request
Bug description:Add an short alias DS for DIRECTORY_SEPARATOR

Description:

Really hope there is a DS alias for DIRECTORY_SEPARATOR, and
PATH_SEPARATOR.

because it's too easy to make a typo, these keywords are hard to type.

$path = 'root' . DS . 'to' . 'path' . DS . 'subpath' . DS . 'subpath' . DS
. 
'file.txt';

rather than:

$path = 'root' . DIRECTORY_SEPARATOR . 'to' . 'path' . DIRECTORY_SEPARATOR
. 
'subpath' . DIRECTORY_SEPARATOR . 'subpath' . DIRECTORY_SEPARATOR .
'file.txt';

the later is uglier. 


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

Req #54003 [Com]: re-enable abstract static methods

[cgili at yahoo dot com]

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

 ID: 54003
 Comment by: cgili at yahoo dot com
 Reported by:giorgio dot liscio at email dot it
 Summary:re-enable abstract static methods
 Status: Open
 Type:   Feature/Change Request
 Package:Class/Object related
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Inheritance and method override is something really important on PHP, it's 
important to redefine not only the methods but also the parameters they take, 
for instance, you have a class Rectangle with a method called Area that 
calculates the area in m2 by requiring the height and width, now you want to 
create a Cube class extending the Rectangle class, and override the function 
Area to calculate the area in cubic meters, the formula is different and the 
parameters are 3, height, width and deep. It's the very "BASIC" definition of 
Class inheritance and Method Overriding.


Previous Comments:

[2011-02-13 00:14:32] giorgio dot liscio at email dot it

Description:

hi, please read carefully my request before trash this

since static inheritance is now implemented in php, enabling this again can 
provide an awesome natural feature of the language

I talked with some php hackers, and they agree with me, but in past, I did not 
have good news about this:

I'm sure my example makes totally sense, and this should stay disabled only if 
there are technical limitations that do not matter with the good logic of my 
example

in practice, I can understand WONT FIX, but not BOGUS

abstract class AFileSystemItem
{
 public static functiongetIfValid   ($fullPath)
 {
  // i use static::isValid to get the method defined in the called class
  if(static::isValid($fullPath)) return new static($fullPath);
 }
 protected function__construct  ($fp){}

 // i want to force real classes to implement a way to check a path before 
instance an object
 protected abstract static functionisValid  ($fullPath); // 
abstract declaration
}

class Dir extends AFileSystemItem
{
 protected static function isValid  ($fullPath)  // 
implementation
 {
 return is_dir($fullPath);
 }
}

class File extends AFileSystemItem
{
 protected static function isValid  ($fullPath)  // 
implementation
 {
 return is_file($fullPath);
 }
}

class Image extends File
{
 protected static function isValid  ($fullPath)  // 
implementation with override
 {
 if(parent::isValid($fullPath) AND (bool)getimagesize($fullPath)) 
return true; return false;
 }
}







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

Bug #61292 [Ver->Csd]: Segfault while calling a method on an overloaded PDO object.

[laruence]

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

 ID: 61292
 Updated by: larue...@php.net
 Reported by:julien at palard dot fr
 Summary:Segfault while calling a method on an overloaded PDO
 object.
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux 2.6.32-amd64
 PHP Version:5.4.0
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-03-06 03:45:19] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=323935
Log: Fixed bug #61292 (Segfault while calling a method on an overloaded PDO 
object)


[2012-03-05 22:17:48] johan...@php.net

(gdb) bt
#0  0x084de050 in zend_std_read_property (object=0x893ebcc, member=0x893d558, 
type=0, key=0x893d558)
at branches/PHP_5_4/Zend/zend_object_handlers.c:433
#1  0x0857c5a9 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST (
execute_data=0x891f190)
at branches/PHP_5_4/Zend/zend_vm_execute.h:21797
#2  0x0857c60e in ZEND_FETCH_OBJ_R_SPEC_UNUSED_CONST_HANDLER (
execute_data=0x891f190)
at branches/PHP_5_4/Zend/zend_vm_execute.h:21815
#3  0x084ea3bb in execute (op_array=0x893d428)
at branches/PHP_5_4/Zend/zend_vm_execute.h:410
#4  0x084a29c2 in dtrace_execute (op_array=0x893d428)
at branches/PHP_5_4/Zend/zend_dtrace.c:75
#5  0x084eb8d4 in zend_do_fcall_common_helper_SPEC (execute_data=0x891f0d4)
at branches/PHP_5_4/Zend/zend_vm_execute.h:669
#6  0x084ec3df in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x891f0d4)
at branches/PHP_5_4/Zend/zend_vm_execute.h:752
#7  0x084ea3bb in execute (op_array=0x893b330)
at branches/PHP_5_4/Zend/zend_vm_execute.h:410
#8  0x084a29c2 in dtrace_execute (op_array=0x893b330)
at branches/PHP_5_4/Zend/zend_dtrace.c:75
#9  0x084b5d2d in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at branches/PHP_5_4/Zend/zend.c:1272
#10 0x0843e29a in php_execute_script (primary_file=0x80474b8)
at branches/PHP_5_4/main/main.c:2473
#11 0x085ca879 in do_cli (argc=1, argv=0x8047804)
at branches/PHP_5_4/sapi/cli/php_cli.c:983
#12 0x085cb8fb in main (argc=1, argv=0x8047804)
at branches/PHP_5_4/sapi/cli/php_cli.c:1356


[2012-03-05 16:58:24] julien at palard dot fr

Description:

Just check the simple code in the "Test script", it lead to the segfault.

Seems that it only segfault when ATTR_PERSISTENT is set.




Test script:
---
 TRUE);
parent::__construct("mysql:host=***;dbname=***;charset=utf8", '***', 
'***', $options);
}

var $bar = array();

public function foo()
{
var_dump($this->bar);
}
}

(new Melty_Database_SQL)->foo();

Expected result:

No segfault !

Actual result:
--
Segfault !






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

Bug #60515 [Com]: "Invalid parameter number" although it is correct

[jeffvanb at u dot washington dot edu]

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

 ID: 60515
 Comment by: jeffvanb at u dot washington dot edu
 Reported by:phoenixseve at freenet dot de
 Summary:"Invalid parameter number" although it is correct
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   archlinux x86_64
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

This misleading error message is also thrown when you include a single-line 
comment that contains a single-quote. 

Example:

SELECT something
-- This valid SQL syntax shouldn't be a problem
FROM somewhere
WHERE value = :v;

PDO will tell you the parameter count is mismatched and you will pull your hair 
out wondering what is wrong.


Previous Comments:

[2011-12-13 20:57:47] phoenixseve at freenet dot de

Description:

When I execute the attached test script an exception is thrown with the message:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not 
match number of tokens

The exception is raised in the execute() line.

If you change the WHERE clause to `id`=24 there is no error message.
The same is true for this query: UPDATE `edtable` SET `id`=:p0 WHERE `id`='24'

The generated error message is obviously not correct. I don't even see why an 
error message is generated as the request seems valid (although strange) to me.

Test script:
---
$createTableSql = <<<'EOT'
DROP TABLE IF EXISTS `edtable`;
CREATE TABLE IF NOT EXISTS `edtable` (
  `id` bigint(20) NOT NULL,
  `coun't()` varchar(20) NOT NULL
);
EOT;

  $pdo = new PDO('mysql:host=localhost;dbname=aynte','aynte','aynte');
  $pdo->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);

  $result = $pdo->query($createTableSql);
  $result->closeCursor();

  $stmt = $pdo->prepare("UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE 
`id`='24'");
  $stmt->execute(array(':p0'=>'2', ':p1'=>'b2' ));

Expected result:

No error message.

Actual result:
--
PHP Fatal error:  Uncaught exception 'PDOException' with message 
'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not 
match number of tokens' in /srv/http/test.php:19\nStack trace:\n#0 
/srv/http/test.php(19): PDOStatement->execute(Array)\n#1 {main}\n  thrown in 
/srv/http/test.php on line 19






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

Bug #60683 [Opn->Nab]: Interactive Mode doesn't reach prompt

[johannes]

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

 ID: 60683
 Updated by: johan...@php.net
 Reported by:da...@php.net
 Summary:Interactive Mode doesn't reach prompt
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   OSX 10.7.2 & Ubuntu 11.04
 PHP Version:5.4.0RC5
 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

The classic interactive mode is different from the shell mode, just re-using 
the flag.


Previous Comments:

[2012-01-17 18:30:46] da...@php.net

Can we make the output here 
(http://lxr.php.net/opengrok/xref/PHP_5_4/sapi/cli/php_cli.c#906) be a little 
more descriptive?

i.e.:

printf("Interactive mode enabled\n");
printf("No readline/libedit support, use ^D to execute and quit.\n\n");


[2012-01-16 19:18:01] rk at srsbiz dot pl

@dragoonis 

readline is only required to make this mode truly interactive (with command 
history, function completion etc), but it also works without it. You can 
type/paste your code and it will be executed as soon as EOF (^D) is reached, so 
it's rather documentation problem.


[2012-01-15 01:58:33] dragoo...@php.net

@rk,

If there's support required for another library then it shouldn't let you enter 
interactive mode, and back out, giving you a useful error message to tell you 
there are missing dependencies..


[2012-01-13 21:45:44] rk at srsbiz dot pl

IMHO it's not a bug, to have interactive shell you have to configure with 
readline support, not just clean './configure'


[2012-01-08 05:37:10] dragoo...@php.net

I confirmed this case with davey on Mac OSX Lion

Darwin Paul-Dragooniss-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: 
Tue 
Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
05:10
macosx lion..


My build details are:
--
bash-3.2$ ../build/bin/php -v
PHP 5.4.0RC6-dev (cli) (built: Jan  8 2012 03:03:04) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

Thanks.




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


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

Bug #47802 [Opn->Csd]: PDO_MYSQL doesn't use the charset parameter

[johannes]

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

 ID: 47802
 Updated by: johan...@php.net
 Reported by:disbursement at dublin dot com
 Summary:PDO_MYSQL doesn't use the charset parameter
-Status: Open
+Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   all
 PHP Version:5.2.9
-Assigned To:
+Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php




Previous Comments:

[2011-04-19 11:38:35] johan...@php.net

You can write secure code - if you are using a supported encoding 
(iso-8859-1/latin1, utf-8, ...)


[2011-04-19 01:58:25] ircmaxell at gmail dot com

I won't argue the decision, but I'd like to clarify one point.  Right now, in 
5.2.x (and <=5.3.5) it's impossible to write a secure query using PDO::quote.  
So 
if you use another character set, it would automatically make all code 
vulnerable 
to SQL Injection (with no built-in method to fix it).  So that leaves existing 
the code 3 options: Switch to MySQLi, Implement their own quoting mechanism, or 
switch to prepared statements (the best solution).  But as it stands, the API 
does not deliver its promise. 

Just an observation...


[2011-04-19 01:07:20] johan...@php.net

If a developer shots himself it is noting we can prevent. Tis does not justify 
a security release of PHP as the only one who can exploit this is the one 
writing code ...

This should however be made clear in the documentation: Executing SET NAMES 
doesn't tell anything to the client library (libmysql / mysqlnd used by PHP) so 
they can't do proper encoding. Therefore only Latin 1, Utf-8 and other 
encodings using lower 7 bits in an ASCII compatible way can be used safely. For 
other encodings the mentioned option, introduced later in 5.3.6 should be used.


[2011-04-18 22:38:48] col...@php.net

Re-opening because of 5_2 backport request by some user.


[2011-04-18 22:34:03] ircmaxell at gmail dot com

Re-opening this as it has security implications for 5.2.x.  It should be 
backported and re-released as a security fix for 5.2.x.

As it stands now, PDO::quote() does not protect against security 
vulnerabilities 
without the ability to set the character set in the C api.  5.3.6 closes this 
hole when supplied with the optional charset parameter (by appropriately 
setting 
the character set).  However this will need to be expressed in the 
documentation 
(I will file another issue on this topic).

Proof Of Concept Code:

$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());

Expected: int(0)
Actual: the number of tables on the server




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


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

Bug #61288 [Opn->Csd]: pdo_mysql___construct_options_libmysql.phpt test fails

[johannes]

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

 ID: 61288
 Updated by: johan...@php.net
 Reported by:r...@php.net
 Summary:pdo_mysql___construct_options_libmysql.phpt test
 fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4.0
-Assigned To:
+Assigned To:johannes
 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-06 01:43:42] johan...@php.net

Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=323932
Log: Apply test fix for bug #61288 pdo_mysql___construct_options_libmysql.phpt 
test fails


[2012-03-05 15:19:32] r...@php.net

Description:

When no connexion is available, this test should not fails but be skipped (as 
the others)

Please see trivial patch attached

Sorry, I don't find a "pdo_mysql" in package list

Test script:
---
pear run-tests pdo_mysql___construct_options_libmysql.phpt

Expected result:

Running 1 tests
SKIP MySQL PDO->__construct(), libmysql only 
options[pdo_mysql___construct_options_libmysql.phpt](reason: SQLSTATE[28000] 
[1045] Access denied for user 'root'@'localhost' (using password: NO))
TOTAL TIME: 00:00
0 PASSED TESTS
1 SKIPPED TESTS


Actual result:
--
Running 1 tests
FAIL MySQL PDO->__construct(), libmysql only 
options[pdo_mysql___construct_options_libmysql.phpt]
wrote log to "/dev/shm/php-5.4.0/ext/pdo_mysql/tests/run-tests.log"
TOTAL TIME: 00:01
0 PASSED TESTS
0 SKIPPED TESTS
1 FAILED TESTS:







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

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

[johannes]

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

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

 New Comment:

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.


Previous Comments:

[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 #53287 [Asn->Nab]: PDO 5 Byte write to a broken pipe when forked

[johannes]

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

 ID: 53287
 Updated by: johan...@php.net
 Reported by:bryan dot tong at gigenet dot com
 Summary:PDO 5 Byte write to a broken pipe when forked
-Status: Assigned
+Status: Not a bug
 Type:   Bug
 Package:PDO related
 Operating System:   CentOS 5.5 x86-64
 PHP Version:5.3SVN-2010-11-10 (snap)
 Assigned To:mysql
 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




Previous Comments:

[2011-01-31 10:42:56] bryan dot tong at gigenet dot com

Though it can really make parsing the output a pain when there are multiple 
versions of mysqlnd floating about.


[2011-01-31 10:27:42] u...@php.net

This does not smell like an error rather more like mysqlnd being more verbose. 
No bug, a feature, I'd say.


[2010-12-05 21:23:46] seza at paradoxal dot org

I have the same error message with php.5.3.3 (send of 5 bytes failed with 
errno=32 Broken pipe) but in a 
different context more simply to reproduce :

I have a simple website (no fork or stuff like that). It make persistent 
connection with pdo to mysql 
(mysqlnd). The errors are raised when the mysql is server is restarted.

When mysql server is off error message are mysql server is gone away. No 
problem with that but once the 
mysql server is restarted and during 15 minutes I have sometimes this error 
message (send of 5 bytes 
failed with errno=32 Broken pipe). 
Certainly a reuse of a cached connection to mysql before it was restarted.

PS : I use mysql_sock connection (mysql:unix_socket=/var/run/mysqld/mysqld.sock)


[2010-11-26 13:19:45] johan...@php.net

The description mentions forking, the sample code not. Please provide a 
complete script showing the issue.


[2010-11-10 03:21:00] bryan dot tong at gigenet dot com

Description:

When switching from PHP 5.1.6 to PHP 5.3.3 the following notice has begun to 
show up in our scripts.

PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe

We are running a daemon and the forked children throw this error on the PDO 
construct that is used to refresh the class.

The error changes depending on whether a persistent connection is set or not.

When persistent is on the above error is produced. Without persistent 
connection applied the error is thrown when the class is destructed.

Example: $pdo = null;
send of 5 bytes failed with errno=32 Broken pipe

We have confirmed this to be apparent in PHP 5.3.3 and the trunk build. I was 
unable to test on 5.2, but I was able to confirm this bug does not occur on 
5.1.6

I have tried wrapping ob functions around the calls in case the broken pipe 
happened to be stdout but I think it is the mysql socket that is in question. 
On that same note, switching mysql to connect via tcp did not help.

>From searching I found a site that threw this error but no discussions of it.

Let me know any additional information that is needed.

Test script:
---
// without persistance
public static function shutdown(){
$base = Base::getBase();
$base->db = null;
self::$base = false;
}

// with persistance
$this->pdo = new PDO(
$dsn,
$user,
$pass,
array(
PDO::ATTR_ERRMODE   =>  PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT=>  true
)
);

Expected result:

The PDO class should startup quietly when persistent connections are enabled 
and destruct quietly when persistent connections are disabled.

Actual result:
--
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe with 
persistent connections.

Base::shutdown(): send of 5 bytes failed with errno=32 Broken pipe without 
persistent connections.

I believe this problem is only related to forked processes. I have confirmed 
the standard page serving to not throw this.










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

Bug #61003 [Asn->Csd]: mysql_stat() require a valid connection

[johannes]

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

 ID: 61003
 Updated by: johan...@php.net
 Reported by:rein at basefarm dot no
 Summary:mysql_stat() require a valid connection
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux and Solaris
 PHP Version:5.3.10
 Assigned To:mysql
 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-06 00:15:32] johan...@php.net

Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=323931
Log: Fix bug #61003 mysql_stat() require a valid connection


[2012-02-07 14:57:20] rein at basefarm dot no

Description:

Calling mysql_stat() from the mysql library requires a valid connection.  When 
php 5.3.10 is built with the mysql 5.1.58 client library a seg.fault is seen in 
ext/mysqli/tests/bug34810.phpt when it calls var_dump like:

 $link = mysqli_init();
 @var_dump($link);

The attached patch fixes this.








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

Bug #61293 [Com]: assigning 09 to variable

[anon at anon dot anon]

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

 ID: 61293
 Comment by: anon at anon dot anon
 Reported by:donmillhofer at yahoo dot com
 Summary:assigning 09 to variable
 Status: Not a bug
 Type:   Bug
 Package:Variables related
 Operating System:   Windows Vista
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

It's been a bug for 10+ years. To this day nobody at PHP is smart enough to 
turn it into a syntax error condition, like it would be in a good or semi-good 
language.


Previous Comments:

[2012-03-05 18:53:54] ras...@php.net

Yes, you have discovered octal notation.

http://www.php.net/manual/en/language.types.integer.php


[2012-03-05 18:24:52] donmillhofer at yahoo dot com

Description:

My concern is that PHP treats the handling of variable assignment 
inconsistently.  For example if I assign 01 to a variable $i01 the result will 
be an int 1, the same as if I had assigned 1 to the variable.  This works for 
values of 01,02,03,04,05,06, and 07.  However 08 and 09 are assigned as 0!

See repeatable test below.



Test script:
---
Assign variables:
$s09 = '09';
$c09 = (integer) '09';
   $i09 = 09;

Result of var_dump($s09.' / '.$c09.' / '.$i09);
string '09 / 9 / 0'

Assign variables:
$s07 = '07';
$c07 = (integer) '07';
   $i07 = 07;

Result of var_dump($s07.' / '.$c07.' / '.$i07);
string '07 / 7 / 7'

And when I just dump the $iXX variable I get:

var_dump($i09);
Result  int 0

var_dump($i07);
Result  int 7

This looks like a bug to me. 







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

Bug #60948 [Asn->Csd]: mysqlnd FTBFS when -Wformat-security is enabled

[johannes]

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

 ID: 60948
 Updated by: johan...@php.net
 Reported by:ond...@php.net
 Summary:mysqlnd FTBFS when -Wformat-security is enabled
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   Any
 PHP Version:5.4.0RC6
 Assigned To:mysql
 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-05 23:55:04] johan...@php.net

Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=323929
Log: Fix bug #60948 mysqlnd FTBFS when -Wformat-security is enabled

# 5.3 not affected


[2012-02-01 13:37:24] johan...@php.net

As a remark: The patch is not strictly needed - the msg is a const char* 
without any risk of injecting anything ... therefore not critical.


[2012-02-01 13:34:47] johan...@php.net

Patch looks good, checking with RM before committing.


[2012-02-01 13:10:40] ond...@php.net

Description:

$ svn diff
Index: ext/mysqlnd/mysqlnd_wireprotocol.c
===
--- ext/mysqlnd/mysqlnd_wireprotocol.c  (revision 322993)
+++ ext/mysqlnd/mysqlnd_wireprotocol.c  (working copy)
@@ -500,7 +500,7 @@
const char * const msg = "Authentication data too long. 
"
"Won't fit into the buffer and will be 
truncated. Authentication will thus fail";
SET_CLIENT_ERROR(*conn->error_info, CR_UNKNOWN_ERROR, 
UNKNOWN_SQLSTATE, msg);
-   php_error_docref(NULL TSRMLS_CC, E_WARNING, msg);
+   php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s", msg);
DBG_RETURN(0);
}   









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

Bug #61194 [Asn->Csd]: PDO should export compression flag with myslqnd

[johannes]

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

 ID: 61194
 Updated by: johan...@php.net
 Reported by:johan...@php.net
 Summary:PDO should export compression flag with myslqnd
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   *
 PHP Version:trunk-SVN-2012-02-27 (SVN)
 Assigned To:mysql
 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-02-27 14:17:55] johan...@php.net

To be committed after 5.4.0


[2012-02-27 14:17:03] johan...@php.net

The following patch has been added/updated:

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


[2012-02-27 14:16:47] johan...@php.net

Description:

pdo_mysql.c has this code:

107 #ifndef PDO_USE_MYSQLND
/* ... */
111 REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_COMPRESS", 
(long)PDO_MYSQL_ATTR_COMPRESS);
112 #endif

This attribute should be provided for mysqlnd builds, too, as compression is 
supported in mysqlnd.







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

Bug #61207 [Asn->Csd]: PDO::nextRowset() after a multi-statement query doesn't always work

[johannes]

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

 ID: 61207
 Updated by: johan...@php.net
 Reported by:acabal at ucla dot edu
 Summary:PDO::nextRowset() after a multi-statement query
 doesn't always work
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10 64-bit
 PHP Version:5.4.0RC8
 Assigned To:mysql
 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-05 23:38:07] johan...@php.net

Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=323928
Log: Fix Bug #61207 PDO::nextRowset() after a multi-statement query doesn't 
always work


[2012-02-29 12:22:27] johan...@php.net

The attached patch should fix it, but needs some tests for PDO weirdness.


[2012-02-29 12:21:48] johan...@php.net

The following patch has been added/updated:

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


[2012-02-29 05:57:00] acabal at ucla dot edu

Oops, a small typo in the linked example script: In the bugged example, I typed 
$handle1 instead of $handle4 in the do loop.  Interestingly the script still 
produces the same bugged output even with the typo.


[2012-02-29 05:45:49] acabal at ucla dot edu

Description:

After executing a single multi-statement query in PDO in which the statements 
are INSERT, followed by UPDATE, followed by SELECT, then trying to loop over 
the results using PDO::nextRowset(), the function returns FALSE (i.e. no more 
rowsets) after the UPDATE rowset, but before reaching the SELECT rowset.  Thus 
the SELECT rowset is lost.

I tried several permutations of multi-statement queries.  INSERT, then SELECT, 
then UPDATE works; SELECT then UPDATE works; UPDATE then SELECT works; only 
INSERT, then UPDATE, then SELECT fails.

See the below code for those examples plus the bugged example.

I originally ran in to this problem on PHP 5.3.5, but it still appears in PHP 
5.4.0RC8.

Test script:
---
First create the following MySQL test db/table:


create database `test`character set utf8 collate utf8_general_ci;
create table `test`.`testtable`( `id` int ); 


Next check this example code to see the bug in action.  There are four examples 
in the code, the first three work, and the last one is the bug.

http://pastebin.com/EKePD6e2

The bug tracker suggested a link for code longer than 20 lines, though I can 
provide the example script directly in this bug report if that would be helpful.

Expected result:

Handle 1:
Rowset 1
Rowset 2
Results detected
Handle 2:
Rowset 1
Results detected
Handle 3:
Rowset 1
Rowset 2
Results detected
Handle 4:
Rowset 1
Rowset 2
Results detected

Actual result:
--
Handle 1:
Rowset 1
Rowset 2
Results detected
Handle 2:
Rowset 1
Results detected
Handle 3:
Rowset 1
Rowset 2
Results detected
Handle 4:
Rowset 1






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

Bug #61290 [Fbk->Csd]: php_sockets build failure - unresolved external symbol _inet_aton

[neweracracker at gmail dot com]

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

 ID: 61290
 User updated by:neweracracker at gmail dot com
 Reported by:neweracracker at gmail dot com
 Summary:php_sockets build failure - unresolved external
 symbol _inet_aton
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows 7
 PHP Version:5.3SVN-2012-03-05 (snap)
 Block user comment: N
 Private report: N

 New Comment:

That did the trick.
Thank you.


Previous Comments:

[2012-03-05 20:55:00] paj...@php.net

Please try using this snapshot:

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

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

Using revision 323926 or later


[2012-03-05 20:53:32] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=323926
Log: - fix bug #61290, fix build


[2012-03-05 20:37:57] neweracracker at gmail dot com

Okay,

I fixed it, win32\inet.h (line 6) change to:
#if (_WIN32_WINNT <= 0x0501)
And it will build.

This will work if win32/build/config.w32.h.in (line 9):
#define _WIN32_WINNT 0x0501


[2012-03-05 20:09:09] neweracracker at gmail dot com

It seems this was caused by the changes of bug 54407 that did cause compile 
time changes over win32\inet.h

Not sure though, leaving note here for further reference.


[2012-03-05 16:00:18] neweracracker at gmail dot com

Description:

   Creating library J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.lib 
and object J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.exp
sockets.obj : error LNK2019: unresolved external symbol _inet_aton referenced 
in function _php_set_inet_addr
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.dll : fatal error 
LNK1120: 1 unresolved externals








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

Bug #61043 [Opn->Ctl]: Regression in magic_quotes_gpc fix (CVE-2012-0831)

[pajoye]

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

 ID: 61043
 Updated by: paj...@php.net
 Reported by:ond...@php.net
 Summary:Regression in magic_quotes_gpc fix (CVE-2012-0831)
-Status: Open
+Status: Critical
 Type:   Bug
 Package:Variables related
 PHP Version:5.3SVN-2012-02-10 (SVN)
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

Johannes, can you check this please?


Previous Comments:

[2012-02-13 18:37:04] sbeat...@php.net

Ondřej's patch is the patch we went with in Ubuntu. I verified in our testing 
that it did address the issue.


[2012-02-10 13:19:41] ond...@php.net

I can confirm that the attached patch fixes the reported problem:

root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php  -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini 
magic_quotes_gpc = On
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php  -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(1) "1"
root@howl:/tmp# emacs php.ini 
root@howl:/tmp# grep ^magic_quotes_gpc /tmp/php.ini 
magic_quotes_gpc = Off
root@howl:/tmp# /tmp/buildd/php5-5.3.3/cgi-build/sapi/cli/php  -c /tmp/php.ini -
r 'var_dump(ini_get("magic_quotes_gpc"));'
string(0) ""


[2012-02-10 12:44:17] ond...@php.net

The following patch has been added/updated:

Patch Name: magic_quotes_gpc-regression
Revision:   1328877857
URL:
https://bugs.php.net/patch-display.php?bug=61043&patch=magic_quotes_gpc-regression&revision=1328877857


[2012-02-10 12:43:45] ond...@php.net

Description:

Description available here:

https://bugs.launchpad.net/ubuntu/+source/php5/+bug/930115


Basically the attached patch does replace the second location of 
PG(magic_quotes_gpc) with the zend_alter_ini_entry_ex:


-   PG(magic_quotes_gpc) = magic_quotes_gpc;
+
+   if (magic_quotes_gpc) {
+   zend_alter_ini_entry_ex("magic_quotes_gpc", 
sizeof("magic_quotes_gpc"), "1", 1, ZEND_INI_SYSTEM, ZEND_INI_STAGE_ACTIVATE, 1 
TSRMLS_CC);
+   }

I could be wrong, since my knowledge of PHP internals is lim(knowledge) = 0, 
but 
this seems to follow the logic of first change.







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

[PHP-BUG] Bug #61295 [NEW]: php-fpm should not fail with commented 'user' for non-root start

[s...@php.net]

From: sixd
Operating system: Linux
PHP version:  5.4.0
Package:  FPM related
Bug Type: Bug
Bug description:php-fpm should not fail with commented 'user' for non-root start

Description:

For non-root users:

 1. if php-fpm.config has the default 'user = nobody' then php-fpm starts
with:
  "WARNING: [pool www] 'user' directive is ignored when FPM is not
running as 
root"

 2. But if the 'user' directive is commented out then php-fpm fails
to start and gives "ALERT: [pool www] user has not been defined"


Php-fpm should not fail to start for non root users when 'user' (and
probably 
'group') are commented out of php-fpm.conf


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

Bug #61292 [Opn->Ver]: Segfault while calling a method on an overloaded PDO object.

[johannes]

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

 ID: 61292
 Updated by: johan...@php.net
 Reported by:julien at palard dot fr
 Summary:Segfault while calling a method on an overloaded PDO
 object.
-Status: Open
+Status: Verified
 Type:   Bug
 Package:PDO related
 Operating System:   Linux 2.6.32-amd64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

(gdb) bt
#0  0x084de050 in zend_std_read_property (object=0x893ebcc, member=0x893d558, 
type=0, key=0x893d558)
at branches/PHP_5_4/Zend/zend_object_handlers.c:433
#1  0x0857c5a9 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST (
execute_data=0x891f190)
at branches/PHP_5_4/Zend/zend_vm_execute.h:21797
#2  0x0857c60e in ZEND_FETCH_OBJ_R_SPEC_UNUSED_CONST_HANDLER (
execute_data=0x891f190)
at branches/PHP_5_4/Zend/zend_vm_execute.h:21815
#3  0x084ea3bb in execute (op_array=0x893d428)
at branches/PHP_5_4/Zend/zend_vm_execute.h:410
#4  0x084a29c2 in dtrace_execute (op_array=0x893d428)
at branches/PHP_5_4/Zend/zend_dtrace.c:75
#5  0x084eb8d4 in zend_do_fcall_common_helper_SPEC (execute_data=0x891f0d4)
at branches/PHP_5_4/Zend/zend_vm_execute.h:669
#6  0x084ec3df in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x891f0d4)
at branches/PHP_5_4/Zend/zend_vm_execute.h:752
#7  0x084ea3bb in execute (op_array=0x893b330)
at branches/PHP_5_4/Zend/zend_vm_execute.h:410
#8  0x084a29c2 in dtrace_execute (op_array=0x893b330)
at branches/PHP_5_4/Zend/zend_dtrace.c:75
#9  0x084b5d2d in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at branches/PHP_5_4/Zend/zend.c:1272
#10 0x0843e29a in php_execute_script (primary_file=0x80474b8)
at branches/PHP_5_4/main/main.c:2473
#11 0x085ca879 in do_cli (argc=1, argv=0x8047804)
at branches/PHP_5_4/sapi/cli/php_cli.c:983
#12 0x085cb8fb in main (argc=1, argv=0x8047804)
at branches/PHP_5_4/sapi/cli/php_cli.c:1356


Previous Comments:

[2012-03-05 16:58:24] julien at palard dot fr

Description:

Just check the simple code in the "Test script", it lead to the segfault.

Seems that it only segfault when ATTR_PERSISTENT is set.




Test script:
---
 TRUE);
parent::__construct("mysql:host=***;dbname=***;charset=utf8", '***', 
'***', $options);
}

var $bar = array();

public function foo()
{
var_dump($this->bar);
}
}

(new Melty_Database_SQL)->foo();

Expected result:

No segfault !

Actual result:
--
Segfault !






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

Bug #61246 [Com]: Error when running PHP-FPM

[dancom96 at gmail dot com]

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

 ID: 61246
 Comment by: dancom96 at gmail dot com
 Reported by:osmanungur at gmail dot com
 Summary:Error when running PHP-FPM
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Mac Os X 10.7.3
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Exact same issue with PHP 5.4.0, APC 3.1.9 but on CentOS 6.

Gives error starting PHP-FPM and says failed, but PHP-FPM does actually start 
and 
APC appears to work fully. (Page generation time goes down to 1/4 of original 
gen 
time on Wordpress, like my production server)


Previous Comments:

[2012-03-05 10:23:50] takida at nm dot ru

If it would help, apache is running as MPM-Prefork. Everything else is pretty 
standard.


[2012-03-05 10:02:18] takida at nm dot ru

I'm experiencing the same bug as the guy with Ubuntu yet on CentOS 5.7 with 
Apache. Same php version, same APC version, almost the same error:
*** glibc detected *** php-fpm: master process (/usr/lib/php-5.4.0-
custom/etc/php-fpm.conf): free(): invalid pointer: 0xb72a1010 ***

What is strange, php-apc was build from source and could not pass the "make 
test" 
step completely. When disabling APC everything is fine, otherwise php doesn't 
work at all.


[2012-03-04 08:05:20] rnysmile at yahoo dot com

similar problem in Ubuntu 10.04

# /etc/init.d/php-fpm restart
Gracefully shutting down php-fpm . done
Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): 
invalid 
pointer: 0x7f78b5d45118 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7f78b2e6d5b6]
/lib/libc.so.6(cfree+0x73)[0x7f78b2e73e83]
/usr/local/sbin/php-fpm(destroy_zend_class+0x23d)[0x73953d]
/usr/local/sbin/php-fpm(zend_hash_clean+0x73)[0x74e7e3]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f78b0285460]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_module_shutdown+0x12a)[0x7f78b027d8fa]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(+0xb07f)
[0x7f78b027407f]
/usr/local/sbin/php-fpm[0x747855]
/usr/local/sbin/php-fpm[0x74e152]
/usr/local/sbin/php-fpm(zend_hash_graceful_reverse_destroy+0x18)[0x74e3e8]
/usr/local/sbin/php-fpm[0x742443]
/usr/local/sbin/php-fpm(php_module_shutdown+0x2d)[0x6e671d]
/usr/local/sbin/php-fpm[0x7f12b9]
/usr/local/sbin/php-fpm[0x7e958e]
/usr/local/sbin/php-fpm[0x7f693a]
/usr/local/sbin/php-fpm[0x7e89c5]
/usr/local/sbin/php-fpm[0x7efb68]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f78b2e14c4d]
/usr/local/sbin/php-fpm[0x42f989]


No error if disable APC.


[2012-03-02 14:54:56] osmanungur at gmail dot com

Description:

Hi,

Today i upgraded my php installation to PHP 5.4, when i running PHP-FPM i'm 
getting this error

➜ sudo php-fpm
php-fpm(20297) malloc: *** error for object 0x10aeb5c00: pointer being freed 
was 
not allocated
*** set a breakpoint in malloc_error_break to debug

FPM still works and responses without problem via Nginx. 
I haven't problem before upgrading PHP (with PHP 5.3.10). I'm running PHP with 
APC 
3.1.9.









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

Bug #61290 [Opn->Fbk]: php_sockets build failure - unresolved external symbol _inet_aton

[pajoye]

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

 ID: 61290
 Updated by: paj...@php.net
 Reported by:neweracracker at gmail dot com
 Summary:php_sockets build failure - unresolved external
 symbol _inet_aton
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows 7
 PHP Version:5.3SVN-2012-03-05 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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

Using revision 323926 or later


Previous Comments:

[2012-03-05 20:53:32] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=323926
Log: - fix bug #61290, fix build


[2012-03-05 20:37:57] neweracracker at gmail dot com

Okay,

I fixed it, win32\inet.h (line 6) change to:
#if (_WIN32_WINNT <= 0x0501)
And it will build.

This will work if win32/build/config.w32.h.in (line 9):
#define _WIN32_WINNT 0x0501


[2012-03-05 20:09:09] neweracracker at gmail dot com

It seems this was caused by the changes of bug 54407 that did cause compile 
time changes over win32\inet.h

Not sure though, leaving note here for further reference.


[2012-03-05 16:00:18] neweracracker at gmail dot com

Description:

   Creating library J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.lib 
and object J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.exp
sockets.obj : error LNK2019: unresolved external symbol _inet_aton referenced 
in function _php_set_inet_addr
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.dll : fatal error 
LNK1120: 1 unresolved externals








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

Bug #61290 [Com]: php_sockets build failure - unresolved external symbol _inet_aton

[neweracracker at gmail dot com]

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

 ID: 61290
 Comment by: neweracracker at gmail dot com
 Reported by:neweracracker at gmail dot com
 Summary:php_sockets build failure - unresolved external
 symbol _inet_aton
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows 7
 PHP Version:5.3SVN-2012-03-05 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Okay,

I fixed it, win32\inet.h (line 6) change to:
#if (_WIN32_WINNT <= 0x0501)
And it will build.

This will work if win32/build/config.w32.h.in (line 9):
#define _WIN32_WINNT 0x0501


Previous Comments:

[2012-03-05 20:09:09] neweracracker at gmail dot com

It seems this was caused by the changes of bug 54407 that did cause compile 
time changes over win32\inet.h

Not sure though, leaving note here for further reference.


[2012-03-05 16:00:18] neweracracker at gmail dot com

Description:

   Creating library J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.lib 
and object J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.exp
sockets.obj : error LNK2019: unresolved external symbol _inet_aton referenced 
in function _php_set_inet_addr
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.dll : fatal error 
LNK1120: 1 unresolved externals








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

Bug #61223 [Asn->Fbk]: php can run oci,but php-fpm oci error

[sixd]

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

 ID: 61223
 Updated by: s...@php.net
 Reported by:4yuinfo at gmail dot com
 Summary:php can run oci,but php-fpm oci error
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:OCI8 related
 Operating System:   CentOS 6.2
 PHP Version:5.3.10
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

Try real error checking with oci_error().  Write the output to a log.

Check all logs to see if there are startup errors, such as libraries not found.

A side comment: since you are using Oracle Instant Client you should not set 
ORACLE_HOME.  If you need access to a tnsnames.ora file, set TNS_ADMIN instead
of ORACLE_HOME.

Can you strace the webserver process and see what calls are being made?

Try building PHP from source and linking oci8 as a static extension not 
"shared".


Previous Comments:

[2012-03-03 02:32:58] 4yuinfo at gmail dot com

cat b.php
#---
http://127.0.0.1:80/b.php
right
#ngixn + php-fpm curl http://127.0.0.1:81/b.php
502 bad gateway 
=> but remove remi 5.3.10 rpm
=> reinstall remi 5.3.5 rpm show right string is work
#---
#1.download CentOS-6.2-x86_64-minimal.iso
#2.install CentOS-6.2-x86_64-minimal.iso
#3.yum add repo remi and nginx
yum install php-* --skip-broken php-mysql #no install php-pecl* and php-pear*
yum install nginx
#4.set nginx and php-fpm
#5.download oracle client oracle-instantclient-11.2.0.1.0*.rpm
#6.rpm -ivh oracle-instantclient-11.2.0.1.0*.rpm
#7.set oracle environment variables in the bashrc and php-fpm
#
#--
# php-fpm.conf
#--
[global]
pid = /var/run/php-fpm/php-fpm.pid
emergency_restart_threshold = 1
emergency_restart_interval = 20m
process_control_timeout = 15m

[test]
listen = 127.0.0.1:5101
listen.allowed_clients = 127.0.0.1
user = nginx
group = nginx
pm = static
pm.max_children = 20
pm.max_requests = 0
pm.status_path = /php-fpm/status
ping.path = /php-fpm/ping
ping.response = pong
request_terminate_timeout = 10m
request_slowlog_timeout = 0
rlimit_files = 65530
rlimit_core = 0
env[HOSTNAME]   = $HOSTNAME
env[ORACLE_HOME]= /usr/lib/oracle/11.2/client64/
env[LD_LIBRARY_PATH]= /usr/lib/oracle/11.2/client64/lib/
env[NLS_LANG]   = "TRADITIONAL CHINESE_TAIWAN.UTF8"
env[TNS_ADMIN]  = /etc/oracle
php_admin_flag[short_open_tag]  = on
php_admin_flag[display_errors]  = on
#
# command line add oracle client environment variables
#
echo -e "export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib/\nexport 
NLS_LANG=\"TRADITIONAL CHINESE_TAIWAN.UTF8\"\nexport TNS_ADMIN=/etc/oracle" >> 
/etc/sysconfig/httpd
echo -e "export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib/\nexport 
NLS_LANG=\"TRADITIONAL CHINESE_TAIWAN.UTF8\"\nexport TNS_ADMIN=/etc/oracle" >> 
/etc/bashrc
echo -e "export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib/\nexport 
NLS_LANG=\"TRADITIONAL CHINESE_TAIWAN.UTF8\"\nexport TNS_ADMIN=/etc/oracle" >> 
/etc/profile
#


[2012-03-02 19:32:15] s...@php.net

Do non-Oracle apps work?  The 502 isn't obviously going to be caused by an 
Oracle problem.

Add error checking on the the oci_connect call and see what message is being 
passed.

What configuration options did you use?

What Oracle client did you use?

What Oracle environment variables have you set?

How/where did you set the variables?

What is your fpm configuration?


[2012-03-01 16:45:46] 4yuinfo at gmail dot com

Description:

update php 5.3.5 to php 5.3.10
php-fpm oci can't run

Test script:
---
cat a.php
-
https://bugs.php.net/bug.php?id=61223&edit=1

Bug #60073 [Csd->Nab]: crypt() creates different output in 5.2.17 and 5.3.8

[joey]

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

 ID: 60073
 Updated by: j...@php.net
 Reported by:christian dot achatz at adventure-php-framework
 Summary:crypt() creates different output in 5.2.17 and 5.3.8
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:*Encryption and hash functions
 Operating System:   Windows 32Bit (Windows XP)
 PHP Version:5.3.8
 Assigned To:joey
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-05 20:11:28] j...@php.net

"$2C9b17FGUTd." is not a valid Blowfish hash. You got this output on earlier 
versions of PHP where CRYPT_BLOWFISH was not supported, or perhaps a buggy 
version 
was being used. PHP 5.3.8 is returning the correct hash.


[2011-10-16 20:52:12] christian dot achatz at adventure-php-framework

Description:

Updating from PHP 5.2.17 to 5.3.8 today I was facing a login ussue with the APF 
user management module that calculates password hashed based on the crypt() 
function. 

Finally, I was able to reduce the problem to one single line with the password 
hash provider implementation that calculates the user's password hash compared 
to the one stored within the database using a static and dynamic salt applied 
to crypt() together with the password. Here are the relevant loc:

public function createPasswordHash($password, $dynamicSalt) {
   return crypt($password . $this->getHardCodedSalt(), '$2a$07$' . $dynamicSalt 
. '$');
}

This call results in different hashes for PHP 5.2.17/Win32 and PHP 5.3.8/Win32 
both operated on a 2.2 Apache. In PHP 5.3.8/Win32 it seems that PHP falls back 
to standard Standard DES since the salt is included as clear-text in the hash 
key. As noted on http://de.php.net/crypt PHP only falls back to it's own 
blowfish implementation in case the system brings no support. Obviously, this 
is not as the manual tells us.

The below test script includes the code that I have created to reproduce this 
issue both on my local webserver and the CLI.

Test script:
---
Apache version:
// PHP version   : 5.3.8
// Password  : bob marley
// Static salt   : my-secret
// Dynamic salt  : 4eea9621afdad9f067e12d281b84f316
// Password hash : 
$2a$07$4eea9621afdad9f067e12OIcKkEFDgkmF11Aln8i4xX1m8Pv.mXyy
//
// $ ./php -f ../Apache2.2/htdocs/www/crypt_issue.php
// Apache version:
// PHP version   : 5.2.17
// Password  : bob marley
// Static salt   : my-secret
// Dynamic salt  : 4eea9621afdad9f067e12d281b84f316
// Password hash : $2C9b17FGUTd.
?>

Expected result:

The expected result is "$2C9b17FGUTd." for the password hash both for PHP 
5.2.17/Win32 and PHP 5.3.8/Win32.

Actual result:
--
The actual result is "$2C9b17FGUTd." for PHP 5.2.17/Win32 and 
"$2a$07$4eea9621afdad9f067e12OIcKkEFDgkmF11Aln8i4xX1m8Pv.mXyy" for PHP 
5.3.8/Win32.






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

Bug #60073 [Opn->Csd]: crypt() creates different output in 5.2.17 and 5.3.8

[joey]

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

 ID: 60073
 Updated by: j...@php.net
 Reported by:christian dot achatz at adventure-php-framework
 Summary:crypt() creates different output in 5.2.17 and 5.3.8
-Status: Open
+Status: Closed
 Type:   Bug
-Package:hash related
+Package:*Encryption and hash functions
 Operating System:   Windows 32Bit (Windows XP)
 PHP Version:5.3.8
-Assigned To:
+Assigned To:joey
 Block user comment: N
 Private report: N

 New Comment:

"$2C9b17FGUTd." is not a valid Blowfish hash. You got this output on earlier 
versions of PHP where CRYPT_BLOWFISH was not supported, or perhaps a buggy 
version 
was being used. PHP 5.3.8 is returning the correct hash.


Previous Comments:

[2011-10-16 20:52:12] christian dot achatz at adventure-php-framework

Description:

Updating from PHP 5.2.17 to 5.3.8 today I was facing a login ussue with the APF 
user management module that calculates password hashed based on the crypt() 
function. 

Finally, I was able to reduce the problem to one single line with the password 
hash provider implementation that calculates the user's password hash compared 
to the one stored within the database using a static and dynamic salt applied 
to crypt() together with the password. Here are the relevant loc:

public function createPasswordHash($password, $dynamicSalt) {
   return crypt($password . $this->getHardCodedSalt(), '$2a$07$' . $dynamicSalt 
. '$');
}

This call results in different hashes for PHP 5.2.17/Win32 and PHP 5.3.8/Win32 
both operated on a 2.2 Apache. In PHP 5.3.8/Win32 it seems that PHP falls back 
to standard Standard DES since the salt is included as clear-text in the hash 
key. As noted on http://de.php.net/crypt PHP only falls back to it's own 
blowfish implementation in case the system brings no support. Obviously, this 
is not as the manual tells us.

The below test script includes the code that I have created to reproduce this 
issue both on my local webserver and the CLI.

Test script:
---
Apache version:
// PHP version   : 5.3.8
// Password  : bob marley
// Static salt   : my-secret
// Dynamic salt  : 4eea9621afdad9f067e12d281b84f316
// Password hash : 
$2a$07$4eea9621afdad9f067e12OIcKkEFDgkmF11Aln8i4xX1m8Pv.mXyy
//
// $ ./php -f ../Apache2.2/htdocs/www/crypt_issue.php
// Apache version:
// PHP version   : 5.2.17
// Password  : bob marley
// Static salt   : my-secret
// Dynamic salt  : 4eea9621afdad9f067e12d281b84f316
// Password hash : $2C9b17FGUTd.
?>

Expected result:

The expected result is "$2C9b17FGUTd." for the password hash both for PHP 
5.2.17/Win32 and PHP 5.3.8/Win32.

Actual result:
--
The actual result is "$2C9b17FGUTd." for PHP 5.2.17/Win32 and 
"$2a$07$4eea9621afdad9f067e12OIcKkEFDgkmF11Aln8i4xX1m8Pv.mXyy" for PHP 
5.3.8/Win32.






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

Bug #61290 [Com]: php_sockets build failure - unresolved external symbol _inet_aton

[neweracracker at gmail dot com]

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

 ID: 61290
 Comment by: neweracracker at gmail dot com
 Reported by:neweracracker at gmail dot com
 Summary:php_sockets build failure - unresolved external
 symbol _inet_aton
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows 7
 PHP Version:5.3SVN-2012-03-05 (snap)
 Block user comment: N
 Private report: N

 New Comment:

It seems this was caused by the changes of bug 54407 that did cause compile 
time changes over win32\inet.h

Not sure though, leaving note here for further reference.


Previous Comments:

[2012-03-05 16:00:18] neweracracker at gmail dot com

Description:

   Creating library J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.lib 
and object J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.exp
sockets.obj : error LNK2019: unresolved external symbol _inet_aton referenced 
in function _php_set_inet_addr
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.dll : fatal error 
LNK1120: 1 unresolved externals








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

Bug #61276 [Nab]: OpenSSL old version

[frenky dot pv at atlas dot cz]

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

 ID: 61276
 User updated by:frenky dot pv at atlas dot cz
 Reported by:frenky dot pv at atlas dot cz
 Summary:OpenSSL old version
 Status: Not a bug
 Type:   Bug
 Package:*Network Functions
 Operating System:   Win 2k3 IIS 6
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I use version 0.9.8.20 OPENSSL.

 The problem has been solved:
 When using curl CURLOPT_SSLVERSION must be set to 3
 All this works.


Previous Comments:

[2012-03-05 18:44:46] paj...@php.net

Please use the 0.9.x version of openssl.

With IIS you can use fastcgi and PHP's own DLLs.


[2012-03-04 18:06:27] frenky dot pv at atlas dot cz

Description:

file(): SSL operation failed with code 1. OpenSSL Error messages:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) in 
C:\Inetpub\KC\class\tab_card.php at line 1452

file(): Failed to enable crypto in C:\Inetpub\KC\class\tab_card.php at line 1452
file(https://.../resetpwd.jsp...): failed to open stream: operation failed in 
C:\Inetpub\...\tab_card.php at line 1452

PHP 5.4 old verse contains the OpenSSL functions that the file has a problem 
with loading the https site, where the version used 1.0.0.x. When you replace 
the files libeay32.dll and libssl32.dll version 0.9.8.20 for 1.0.0.7 and PHP 
(fastcgi) becomes unstable and causes HTTP error 500 (internal error).

Test script:
---
$url = 'http://...';
$out = file( $url );







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

Bug #61293 [Opn->Nab]: assigning 09 to variable

[rasmus]

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

 ID: 61293
 Updated by: ras...@php.net
 Reported by:donmillhofer at yahoo dot com
 Summary:assigning 09 to variable
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Variables related
 Operating System:   Windows Vista
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Yes, you have discovered octal notation.

http://www.php.net/manual/en/language.types.integer.php


Previous Comments:

[2012-03-05 18:24:52] donmillhofer at yahoo dot com

Description:

My concern is that PHP treats the handling of variable assignment 
inconsistently.  For example if I assign 01 to a variable $i01 the result will 
be an int 1, the same as if I had assigned 1 to the variable.  This works for 
values of 01,02,03,04,05,06, and 07.  However 08 and 09 are assigned as 0!

See repeatable test below.



Test script:
---
Assign variables:
$s09 = '09';
$c09 = (integer) '09';
   $i09 = 09;

Result of var_dump($s09.' / '.$c09.' / '.$i09);
string '09 / 9 / 0'

Assign variables:
$s07 = '07';
$c07 = (integer) '07';
   $i07 = 07;

Result of var_dump($s07.' / '.$c07.' / '.$i07);
string '07 / 7 / 7'

And when I just dump the $iXX variable I get:

var_dump($i09);
Result  int 0

var_dump($i07);
Result  int 7

This looks like a bug to me. 







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

Bug #61276 [Opn->Nab]: OpenSSL old version

[pajoye]

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

 ID: 61276
 Updated by: paj...@php.net
 Reported by:frenky dot pv at atlas dot cz
 Summary:OpenSSL old version
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Network Functions
 Operating System:   Win 2k3 IIS 6
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Please use the 0.9.x version of openssl.

With IIS you can use fastcgi and PHP's own DLLs.


Previous Comments:

[2012-03-04 18:06:27] frenky dot pv at atlas dot cz

Description:

file(): SSL operation failed with code 1. OpenSSL Error messages:
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112) in 
C:\Inetpub\KC\class\tab_card.php at line 1452

file(): Failed to enable crypto in C:\Inetpub\KC\class\tab_card.php at line 1452
file(https://.../resetpwd.jsp...): failed to open stream: operation failed in 
C:\Inetpub\...\tab_card.php at line 1452

PHP 5.4 old verse contains the OpenSSL functions that the file has a problem 
with loading the https site, where the version used 1.0.0.x. When you replace 
the files libeay32.dll and libssl32.dll version 0.9.8.20 for 1.0.0.7 and PHP 
(fastcgi) becomes unstable and causes HTTP error 500 (internal error).

Test script:
---
$url = 'http://...';
$out = file( $url );







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

Bug #60268 [Com]: Compiling PHP fails

[dedalo at doramail dot com]

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

 ID: 60268
 Comment by: dedalo at doramail dot com
 Reported by:rich06 at gmail dot com
 Summary:Compiling PHP fails
 Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OS X 10.7.2 (Lion)
 PHP Version:5.3.8
 Assigned To:patrickallaert
 Block user comment: N
 Private report: N

 New Comment:

This is a still an issue men and it's not related to --with-apxs2. This is my 
configure command line:

sudo ./configure --prefix=/usr/local --with-apxs2=/usr/sbin/apxs 
--with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr 
--enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets 
--with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc 
--sysconfdir=/private/etc --with-mysql-sock=/var/mysql/mysql.sock 
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-openssl=/usr --with-xmlrpc 
--with-xsl=/usr --without-pear --with-libxml-dir=/usr 
--with-iconv-dir=/opt/local --with-gd --with-jpeg-dir=/opt/local 
--with-png-dir=/opt/local --with-freetype-dir=/opt/local 
--with-mcrypt=/opt/local

As you can see, there is a file path for apsx2 option: 
--with-apxs2=/usr/sbin/apxs

But the make still fails. To make it work, I changed the Makefile, in 
particular the MH_BUNDLE_FLAGS, like suggested by rich06, as follow: 
-L/opt/local/lib

This is a bug, and it's still there. Reopen it, please.


Previous Comments:

[2011-12-08 10:43:44] lolautruche at gmail dot com

I don't agree here, as ./configure --help says:

  --with-apxs2=FILE Build shared Apache 2.0 Handler module. FILE is the 
optional
  pathname to the Apache apxs tool apxs

So FILE is optional


[2011-12-08 10:38:54] patrickalla...@php.net

Closing.
Invalid usage of --with-apxs2 which expects a file argument:
--with-apxs2 --with-iconv-dir=/opt/local


[2011-12-08 09:59:43] lolautruche at gmail dot com

There seems to be linked with --with-apxs2 option.
Indeed, I first used --with-apxs2 (without value) and 
--with-iconv-dir=/opt/local 
(macports prefix). Here the compiler will take apxs system default (which is 
/usr/sbin/apxs), and for some reason also makes ignore --with-iconv-dir value.

If I use --with-apxs2=/opt/local/apache2/bin/apxs (apache2 macports prefix), 
then 
everything will be fine.


[2011-12-06 10:02:54] patrickalla...@php.net

This issue should be solved, editing manually the Makefile isn't the way to go.


[2011-12-06 09:37:01] lolautruche at gmail dot com

I confirm the same issue while compiling PHP 5.4RC2.
To reproduce it, you'll need to have MacPorts installed with iconv lib 
installed 
here. Basically, I already have a 5.3.8 built with MacPorts on my system.

Modifying the Makefile as rich06 suggested made it work, but shouldn't this be 
made by configure script ? I tried with --with-iconv-dir=/opt/local/lib, but it 
doesn't seem to work here




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


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

[PHP-BUG] Bug #61293 [NEW]: assigning 09 to variable

[donmillhofer at yahoo dot com]

From: 
Operating system: Windows Vista
PHP version:  5.3.10
Package:  Variables related
Bug Type: Bug
Bug description:assigning 09 to variable

Description:

My concern is that PHP treats the handling of variable assignment
inconsistently.  For example if I assign 01 to a variable $i01 the result
will be an int 1, the same as if I had assigned 1 to the variable.  This
works for values of 01,02,03,04,05,06, and 07.  However 08 and 09 are
assigned as 0!

See repeatable test below.



Test script:
---
Assign variables:
$s09 = '09';
$c09 = (integer) '09';
   $i09 = 09;

Result of var_dump($s09.' / '.$c09.' / '.$i09);
string '09 / 9 / 0'

Assign variables:
$s07 = '07';
$c07 = (integer) '07';
   $i07 = 07;

Result of var_dump($s07.' / '.$c07.' / '.$i07);
string '07 / 7 / 7'

And when I just dump the $iXX variable I get:

var_dump($i09);
Result  int 0

var_dump($i07);
Result  int 7

This looks like a bug to me. 


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

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

[cornelius dot howl at gmail dot com]

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

 ID: 47615
 Comment by: cornelius dot howl at gmail dot com
 Reported by:kenaniah at gmail dot com
 Summary:PDO parameter binding is in clear violation of the
 ISO 9075 standard
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

BTW, My PHP version 5.3.10.

pdo_pgsql

PDO Driver for PostgreSQL => enabled
PostgreSQL(libpq) Version => 9.1.2
Module version => 1.0.2
Revision =>  $Id: pdo_pgsql.c 321634 2012-01-01 13:15:04Z felipe $ 

pdo_sqlite

PDO Driver for SQLite 3.x => enabled
SQLite Library => 3.7.10

pgsql

PostgreSQL Support => enabled
PostgreSQL(libpq) Version => 9.1.2
Multibyte character support => enabled
SSL support => enabled
Active Persistent Links => 0
Active Links => 0


Previous Comments:

[2012-03-05 18:11:35] cornelius dot howl at gmail dot com

Same here. 


setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); 

$db->query( <execute(array( 
  ':name' =>  'Test',
  ':sn' =>  'Test',
  ':subtitle' => '123',
  ':hide' => false,
  ':token' =>  'd862899f5c4b38f6b6a161e77c2936fb5541deb5',
  ':price' =>  0,
  ':content' => '123',
  ':spec' => '123',
  ':created_by' => 1,
  ':created_on' => '2012-03-06T01:37:50+08:00',
));

foreach( $db->query('select * from products') as $item ) {
var_dump( $item ); 
}






Which throws


PHP Fatal error:  Uncaught exception 'PDOException' with message 
'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php:44
Stack trace:
#0 /Users/c9s/git/Work/phifty/pdo_test.php(44): PDOStatement->execute(Array)
#1 {main}
  thrown in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid 
input syntax for type boolean: "" in /Users/c9s/git/Work/phifty/pdo_test.php on 
line 44


[2009-03-10 18:32:51] kenaniah at gmail dot com

Description:

Referencing ISO 9075, PDO does not properly bind boolean parameters when the 
parameter type has not been made known to PDO.

According to the standard, booleans represent a truth, false, or unknown value. 
According to the SQL language definition (feel free to reference SQL-92), the 
SQL equivalents for a boolean value are TRUE, FALSE, and NULL respectively.

The PDO core should automatically convert boolean values to their proper SQL 
counterparts, and it should be the role of the client driver to deal with these 
values if the database platform in question does not support the ISO standard. 

Rather than listing workarounds, we ask that the PDO core be brought into 
compliance with the SQL standards, and that individual database drivers be 
modified to handle the cases in which their underlying database is not 
standards compliant. 

Reproduce code:
---
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));

Expected result:

SQL statement sent to server:

SELECT id FROM table WHERE mybool = FALSE

(unless modified by DB driver due to a lack of standards compliance on the part 
of the DB)

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input
syntax for type boolean: ""' 

^^for Postgres driver (Postgres is an standard compliant DB as far as booleans 
are concerned)






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

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

[cornelius dot howl at gmail dot com]

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

 ID: 47615
 Comment by: cornelius dot howl at gmail dot com
 Reported by:kenaniah at gmail dot com
 Summary:PDO parameter binding is in clear violation of the
 ISO 9075 standard
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Same here. 


setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); 

$db->query( <execute(array( 
  ':name' =>  'Test',
  ':sn' =>  'Test',
  ':subtitle' => '123',
  ':hide' => false,
  ':token' =>  'd862899f5c4b38f6b6a161e77c2936fb5541deb5',
  ':price' =>  0,
  ':content' => '123',
  ':spec' => '123',
  ':created_by' => 1,
  ':created_on' => '2012-03-06T01:37:50+08:00',
));

foreach( $db->query('select * from products') as $item ) {
var_dump( $item ); 
}






Which throws


PHP Fatal error:  Uncaught exception 'PDOException' with message 
'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php:44
Stack trace:
#0 /Users/c9s/git/Work/phifty/pdo_test.php(44): PDOStatement->execute(Array)
#1 {main}
  thrown in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid 
input syntax for type boolean: "" in /Users/c9s/git/Work/phifty/pdo_test.php on 
line 44


Previous Comments:

[2009-03-10 18:32:51] kenaniah at gmail dot com

Description:

Referencing ISO 9075, PDO does not properly bind boolean parameters when the 
parameter type has not been made known to PDO.

According to the standard, booleans represent a truth, false, or unknown value. 
According to the SQL language definition (feel free to reference SQL-92), the 
SQL equivalents for a boolean value are TRUE, FALSE, and NULL respectively.

The PDO core should automatically convert boolean values to their proper SQL 
counterparts, and it should be the role of the client driver to deal with these 
values if the database platform in question does not support the ISO standard. 

Rather than listing workarounds, we ask that the PDO core be brought into 
compliance with the SQL standards, and that individual database drivers be 
modified to handle the cases in which their underlying database is not 
standards compliant. 

Reproduce code:
---
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));

Expected result:

SQL statement sent to server:

SELECT id FROM table WHERE mybool = FALSE

(unless modified by DB driver due to a lack of standards compliance on the part 
of the DB)

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input
syntax for type boolean: ""' 

^^for Postgres driver (Postgres is an standard compliant DB as far as booleans 
are concerned)






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

[PHP-BUG] Bug #61292 [NEW]: Segfault while calling a method on an overloaded PDO object.

[julien at palard dot fr]

From: 
Operating system: Linux 2.6.32-amd64
PHP version:  5.4.0
Package:  PDO related
Bug Type: Bug
Bug description:Segfault while calling a method on an overloaded PDO object.

Description:

Just check the simple code in the "Test script", it lead to the segfault.

Seems that it only segfault when ATTR_PERSISTENT is set.




Test script:
---
 TRUE);
parent::__construct("mysql:host=***;dbname=***;charset=utf8",
'***', '***', $options);
}

var $bar = array();

public function foo()
{
var_dump($this->bar);
}
}

(new Melty_Database_SQL)->foo();

Expected result:

No segfault !

Actual result:
--
Segfault !

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

Bug #61286 [Opn]: If the trailing path that follows a script contains a dot PATH_INFO is not set

[galacticvoid+php at gmail dot com]

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

 ID: 61286
 User updated by:galacticvoid+php at gmail dot com
 Reported by:galacticvoid+php at gmail dot com
 Summary:If the trailing path that follows a script contains
 a dot PATH_INFO is not set
 Status: Open
 Type:   Bug
 Package:Built-in web server
 Operating System:   OSX
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Sorry I was working on this for an hour and I left out the router part.

Using router.php (The only file in __DIR__ is index.php):

   if (file_exists(__DIR__ . '/' . $_SERVER['REQUEST_URI'])) {
 return false;
   } else {
 include_once 'index.php';
   }

The results of $_SERVER['PATH_INFO'] when calling http://localhost:8000/notset 
is: /notset.


The results of $_SERVER['PATH_INFO'] when calling http://localhost:8000/not.set 
is: PHP Notice: Undefined index: 
PATH_INFO.


Previous Comments:

[2012-03-05 16:21:04] reeze dot xia at gmail dot com

I can't reproduce it in OSX.  Are you sure you are running 5.4.0 but not 
previous 
RC versions?


[2012-03-05 13:28:27] galacticvoid+php at gmail dot com

Description:

If the trailing path that follows a script contains a dot the variable 
$_SERVER['PATH_INFO'] is not set.

Test script:
---
http://locahost:8000/index.php/not.set

Expected result:

/not.set

Actual result:
--
PHP Notice: Undefined index: PATH_INFO ...






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

Bug #61291 [Com]: tiger is broken

[r...@php.net]

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

 ID: 61291
 Comment by: r...@php.net
 Reported by:r...@php.net
 Summary:tiger is broken
 Status: Open
 Type:   Bug
 Package:hash related
 Operating System:   GNU/Linux (Fedora 16)
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Seems related to 
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/hash/hash_tiger.c?r1=321634&r2=322437

(8 * (0%8)) != 56


The patch fixes this, and the "old" tests.

I think, this will break the "new" tests (added after the regression was 
introduce)


Previous Comments:

[2012-03-05 16:29:36] r...@php.net

Description:

mhash_001 and mash_003 fails.

For mhash 001
025+ MHASH_TIGER: string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
026+ MHASH_TIGER: string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

Some tests


 PHP 5.1.6

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash 
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash 
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

 PHP 5.3.10

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash 
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash 
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

 PHP 5.4.0

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash 
extension...")));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash 
extension...",true)));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

=== PHP 5.4.0 with patch

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash 
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r  'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash 
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"









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

[PHP-BUG] Bug #61291 [NEW]: tiger is broken

[r...@php.net]

From: remi
Operating system: GNU/Linux (Fedora 16)
PHP version:  5.4.0
Package:  hash related
Bug Type: Bug
Bug description:tiger is broken

Description:

mhash_001 and mash_003 fails.

For mhash 001
025+ MHASH_TIGER: string(48)
"fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
026+ MHASH_TIGER: string(48)
"953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

Some tests


 PHP 5.1.6

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

 PHP 5.3.10

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

 PHP 5.4.0

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"

=== PHP 5.4.0 with patch

php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"

php -r  'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"




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

Bug #61286 [Com]: If the trailing path that follows a script contains a dot PATH_INFO is not set

[reeze dot xia at gmail dot com]

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

 ID: 61286
 Comment by: reeze dot xia at gmail dot com
 Reported by:galacticvoid+php at gmail dot com
 Summary:If the trailing path that follows a script contains
 a dot PATH_INFO is not set
 Status: Open
 Type:   Bug
 Package:Built-in web server
 Operating System:   OSX
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I can't reproduce it in OSX.  Are you sure you are running 5.4.0 but not 
previous 
RC versions?


Previous Comments:

[2012-03-05 13:28:27] galacticvoid+php at gmail dot com

Description:

If the trailing path that follows a script contains a dot the variable 
$_SERVER['PATH_INFO'] is not set.

Test script:
---
http://locahost:8000/index.php/not.set

Expected result:

/not.set

Actual result:
--
PHP Notice: Undefined index: PATH_INFO ...






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

[PHP-BUG] Bug #61290 [NEW]: php_sockets build failure - unresolved external symbol _inet_aton

[neweracracker at gmail dot com]

From: 
Operating system: Windows 7
PHP version:  5.3SVN-2012-03-05 (snap)
Package:  Compile Failure
Bug Type: Bug
Bug description:php_sockets build failure - unresolved external symbol 
_inet_aton

Description:

   Creating library
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.lib and object
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.exp
sockets.obj : error LNK2019: unresolved external symbol _inet_aton
referenced in function _php_set_inet_addr
J:\php-sdk\php5.3-201203051430\Release_TS\php_sockets.dll : fatal error
LNK1120: 1 unresolved externals



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

Bug #53395 [Nab]: FILTER_VALIDATE_EMAIL return false on valid emails

[rasmus]

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

 ID: 53395
 Updated by: ras...@php.net
 Reported by:edanpr at gmail dot com
 Summary:FILTER_VALIDATE_EMAIL return false on valid emails
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   debian
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

This was fixed "ASAP" nearly 2 years ago. Update your PHP.


Previous Comments:

[2012-03-05 15:43:05] al at hosteurope dot de

According to the DENIC Guidelines a hyphen is allowed on very position except 
on 
the third and fourth position:

See: http://www.denic.de/en/denic-domain-guidelines.html

V.
In addition to the TLD ending ".de", a domain may only be comprised of digits 
(0–9), hyphens, the letters A-Z of the Latin alphabet and the other letters 
listed in the Annex. It may neither begin nor end with a hyphen, nor may it 
have 
a hyphen as both its third and fourth characters. No distinction is made 
between 
upper and lower case. The minimum length of a domain is one character and its 
maximum length is 63 characters; if the domain includes characters listed in 
the 
Annex, the decisive criterion for determining the maximum length is the so-
called ACE-encoded form of the domain as defined in Request for Comments 5890.


So please fix this asap, or the filter_vars function is very useless.


[2010-11-25 09:47:33] edanpr at gmail dot com

I think it's very easy to answer this question. Filter according to 
real-world cases, otherwise, you are making this function useless.

People expect to use this function to validate email, if this function return 
false on valid emails, we got a problem and this function becomes useless.

I already had to add a secondary check in my email validation function to 
support multiple dashes domains.


[2010-11-25 06:41:31] ras...@php.net

This comes back to whether we filter according to spec or we filter according 
to 
real-world cases that go against the spec.  The problem with the latter is that 
it 
is not a finite problem.  If we go by the spec we can simply follow the spec 
and 
we are done.  But yes, you are right, there are domains out there that are not 
legal according to the RFCs but have still been issued for whatever reason.  2 
hyphens is definitely not valid in non-IDN domain names.


[2010-11-25 04:39:27] edanpr at gmail dot com

Ok, 2 dots is wrong, but double dash is still a valid domain which means users 
can have email there.

a--b.com - real domain
h--t.com - real domain


[2010-11-25 04:06:44] ahar...@php.net

filter_var() is right in both cases here: domain names can only
include consecutive hyphens when being used for internationalised
domains (which implies that the name is of the form xn--XXX), and the
local part of an e-mail address can't include consecutive dots, per
the grammar in RFC 5322.




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


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

Bug #53395 [Com]: FILTER_VALIDATE_EMAIL return false on valid emails

[al at hosteurope dot de]

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

 ID: 53395
 Comment by: al at hosteurope dot de
 Reported by:edanpr at gmail dot com
 Summary:FILTER_VALIDATE_EMAIL return false on valid emails
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   debian
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

According to the DENIC Guidelines a hyphen is allowed on very position except 
on 
the third and fourth position:

See: http://www.denic.de/en/denic-domain-guidelines.html

V.
In addition to the TLD ending ".de", a domain may only be comprised of digits 
(0–9), hyphens, the letters A-Z of the Latin alphabet and the other letters 
listed in the Annex. It may neither begin nor end with a hyphen, nor may it 
have 
a hyphen as both its third and fourth characters. No distinction is made 
between 
upper and lower case. The minimum length of a domain is one character and its 
maximum length is 63 characters; if the domain includes characters listed in 
the 
Annex, the decisive criterion for determining the maximum length is the so-
called ACE-encoded form of the domain as defined in Request for Comments 5890.


So please fix this asap, or the filter_vars function is very useless.


Previous Comments:

[2010-11-25 09:47:33] edanpr at gmail dot com

I think it's very easy to answer this question. Filter according to 
real-world cases, otherwise, you are making this function useless.

People expect to use this function to validate email, if this function return 
false on valid emails, we got a problem and this function becomes useless.

I already had to add a secondary check in my email validation function to 
support multiple dashes domains.


[2010-11-25 06:41:31] ras...@php.net

This comes back to whether we filter according to spec or we filter according 
to 
real-world cases that go against the spec.  The problem with the latter is that 
it 
is not a finite problem.  If we go by the spec we can simply follow the spec 
and 
we are done.  But yes, you are right, there are domains out there that are not 
legal according to the RFCs but have still been issued for whatever reason.  2 
hyphens is definitely not valid in non-IDN domain names.


[2010-11-25 04:39:27] edanpr at gmail dot com

Ok, 2 dots is wrong, but double dash is still a valid domain which means users 
can have email there.

a--b.com - real domain
h--t.com - real domain


[2010-11-25 04:06:44] ahar...@php.net

filter_var() is right in both cases here: domain names can only
include consecutive hyphens when being used for internationalised
domains (which implies that the name is of the form xn--XXX), and the
local part of an e-mail address can't include consecutive dots, per
the grammar in RFC 5322.


[2010-11-24 12:58:10] edanpr at gmail dot com

Description:

In php 5.3.3 using filter_var to validate email (FILTER_VALIDATE_EMAIL) that 
got more than one period (.) or dash (-) results in error while in 5.3.2 it 
didn't.

t...@h--t.com will return false on 5.3.3 and true on 5.3.2
t.@test.com will return false on 5.3.3 and true on 5.3.2

Test script:
---
https://bugs.php.net/bug.php?id=53395&edit=1

Bug #61287 [Asn->Csd]: A particular string fails to decompress

[mike]

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

 ID: 61287
 Updated by: m...@php.net
 Reported by:yoozer at gmail dot com
 Summary:A particular string fails to decompress
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Zlib related
 Operating System:   *
 PHP Version:5.4.0
 Assigned To:mike
 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-05 15:38:16] m...@php.net

Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=323917
Log: MFH: Fixed bug #61287 (A particular string fails to decompress)


[2012-03-05 15:35:15] m...@php.net

Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=323916
Log: fix bug #61287 (A particular string fails to decompress)


[2012-03-05 15:00:14] paj...@php.net

Not win specific, confirmed on other OSes too.


[2012-03-05 14:14:50] yoozer at gmail dot com

Description:

We use gzdeflate to compress search parameters. When we recently upgraded from 
5.3.8 to 5.4, a slew of error messages appeared. See the test script below. 
We've tried to minimize it, but any changes do not cause the error to trigger.

Changing the variable name "region_id" to "egion_id" results in 90.
Changing the variable name "region_id" to "tegion_id" causes the same error.
Changing the variable name "discipline" to "isciplined" results in 92.

Changing the value assigned to region_id from 1 to 2 results in 92.
Changing the value assigned to region_id from 1 to 4 results in an error.

Test script:
---
$array = array(
'region_id' => 1,
'discipline' => 23,
'degrees' => array(),
'country_id' => 27
);

$serialized = serialize($array);

$deflated = gzdeflate($serialized, 9);
$inflated = gzinflate($deflated);

echo strlen($inflated);

Expected result:

Expected: 92

Actual result:
--
Warning: gzinflate(): data error in D:\Web\Projects\Bench\index.php on line 13
0






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

Req #61277 [Nab]: Feature request: Shared Keyword

[rasmus]

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

 ID: 61277
 Updated by: ras...@php.net
 Reported by:thbley at gmail dot com
 Summary:Feature request: Shared Keyword
 Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   All
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Sure, and that one-liner could be:

session_set_save_handler(new MySessionHandler);

where all that work is done by a userspace implementation.


Previous Comments:

[2012-03-05 10:50:41] thbley at gmail dot com

Magic methods are nice but checking if the extension is available and enabled, 
maybe compile it before, implement the whole interface, define some good error 
handling, include the library, implement the fallback for non-apc, ... a lot of 
work than could be handled by a one-liner.
People love sth. like session_start(); $_SESSION["hello"] = "world"; without 
knowing all the stuff behind it.


[2012-03-05 05:53:56] ras...@php.net

APC will eventually go in, but it is not going to be directly mapped to any 
sort 
of special shared keywords. Like I said, there are plenty of ways to map this 
in 
userspace via the various magic methods.


[2012-03-05 05:44:17] thbley at gmail dot com

I think it shouldn't be a big issue to get a small portion of the apc or 
memcache code in the core and make it stable. In the end of 2005, there was the 
decision to include apc in the core. So I think it is not a bad idea to look at 
this again.


[2012-03-05 03:55:12] ras...@php.net

And APC is still not stable and portable enough to include in PHP, so saying to 
do 
it like APC doesn't mean much. Doing it like APC means not putting it not the 
core. And if you want something just like APC, just use APC. Most of the 
frameworks already do and they include a slower fallback for servers without 
APC.
This is not going to be baked into the object syntax directly since we have all 
the magic methods you need to hook it in yourself.


[2012-03-05 02:26:09] thbley at gmail dot com

> It is a design decision in PHP not to have such global things in PHP itself.

All PHP frameworks are offering some kind of caching with shared disk or shared 
memory. And I haven't seen a bigger project not using this stuff. It's time to 
rethink this decision.

> - correct locking can be hard

I think the way APC does this it, should do it.

> - such a feature makes scaling over multiple servers hard

It would be enough to have it on one server. For those who want more, can still 
send the data to memcache.

Here is a new example: https://gist.github.com/1975954




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


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

[PHP-BUG] Bug #61288 [NEW]: pdo_mysql___construct_options_libmysql.phpt test fails

[r...@php.net]

From: remi
Operating system: GNU/Linux (Fedora 16)
PHP version:  5.4.0
Package:  MySQL related
Bug Type: Bug
Bug description:pdo_mysql___construct_options_libmysql.phpt test fails

Description:

When no connexion is available, this test should not fails but be skipped
(as the others)

Please see trivial patch attached

Sorry, I don't find a "pdo_mysql" in package list

Test script:
---
pear run-tests pdo_mysql___construct_options_libmysql.phpt

Expected result:

Running 1 tests
SKIP MySQL PDO->__construct(), libmysql only
options[pdo_mysql___construct_options_libmysql.phpt](reason:
SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using
password: NO))
TOTAL TIME: 00:00
0 PASSED TESTS
1 SKIPPED TESTS


Actual result:
--
Running 1 tests
FAIL MySQL PDO->__construct(), libmysql only
options[pdo_mysql___construct_options_libmysql.phpt]
wrote log to "/dev/shm/php-5.4.0/ext/pdo_mysql/tests/run-tests.log"
TOTAL TIME: 00:01
0 PASSED TESTS
0 SKIPPED TESTS
1 FAILED TESTS:


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

Bug #55704 [Opn->Csd]: php_flag engine off crashes apache

[j dot amend at gmail dot com]

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

 ID: 55704
 User updated by:j dot amend at gmail dot com
 Reported by:j dot amend at gmail dot com
 Summary:php_flag engine off crashes apache
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Apache2 related
 Operating System:   Gentoo linux
 PHP Version:5.4SVN-2011-09-19 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I just tested upgrading from RC4 and the release version, and I no longer get a 
segfault when I do a config test or graceful/restart.


Previous Comments:

[2011-09-20 16:46:26] j dot amend at gmail dot com

I tried what I could, but I don't know C or how to use gdb properly. It looks 
like var name makes it to _zend_hash_add_or_update intact as arKey, but then 
the address of arKey mysteriously changes inside that function.

Breakpoint 1, _zend_hash_add_or_update (ht=0x10087d120, arKey=0x10088e298 
"engine", nKeyLength=7, pData=0x7fff5fbff330, nDataSize=24, pDest=0x0, flag=1) 
at /Users/Grayling/php5.4-201109192030/Zend/zend_hash.c:201
201 TSRMLS_FETCH();
(gdb) info args
ht = (HashTable *) 0x10087d120
arKey = 0x10088e298 "engine"
nKeyLength = 7
pData = (void *) 0x7fff5fbff330
nDataSize = 24
pDest = (void **) 0x0
flag = 1
(gdb) print arKey
$6 = 0x10088e298 "engine"
(gdb) print &arKey
Address requested for identifier "arKey" which is in register $r13
(gdb) info address arKey
Symbol "arKey" is 

   0x1012e9a70 - 0x1012e9a98: in register rsi
   0x1012e9a98 - 0x1012e9ace: in register r13
   0x1012e9ace - 0x1012e9b94: in register rcx
   0x1012e9b94 - 0x1012e9bc1: in register r13
   0x1012e9bc1 - 0x1012e9c7c: in register rcx
   0x1012e9c7c - 0x1012e9cd2: in register r13
   0x1012e9d7f - 0x1012e9d8a: in register r13
   0x1012e9d90 - 0x1012e9d9e: in register r13
   0x1012e9da4 - 0x1012e9dff: in register r13
   0x1012e9e2b - 0x1012e9f0f: in register r13
   0x1012e9f15 - 0x1012e9f45: in register r13
   0x1012e9fb5 - 0x1012e9fc6: in register r13
   0x1012e9fd9 - 0x1012e9ff1: in register r13
   0x1012ea00a - 0x1012ea02b: in register r13
   0x1012ea062 - 0x1012ea0b0: in register r13.

(gdb) next
(gdb) print arKey
$6 = 0x10088e298 "engine"
(gdb) p/x $rcx
$17 = 0x10088e298
[...]
(gdb) next
278 case 6: hash = ((hash << 5) + hash) + *arKey++; /* 
fallthrough... */
(gdb) p/x $rcx
$18 = 0x10088e299
[...]
(gdb) next
283 case 1: hash = ((hash << 5) + hash) + *arKey++; break;
(gdb) p/x $rcx
$21 = 0x10088e29e
(gdb) print (char*)0x10088e29e
$22 = 0x10088e29e ""
(gdb) next
218 p = ht->arBuckets[nIndex];
(gdb) print arKey
$24 = 0x10088e29e ""
(gdb) p/x *arKey
$27 = 0x0
[...]
(gdb) next
Breakpoint 8, _zend_hash_add_or_update (ht=0x10087d120, arKey=0x10088e298 
"engine", nKeyLength=7, pData=0x7fff5fbff330, nDataSize=24, pDest=0x0, flag=1) 
at /Users/Grayling/php5.4-201109192030/Zend/zend_hash.c:253
253 p = (Bucket *) pemalloc(sizeof(Bucket) + nKeyLength, 
ht->persistent);
(gdb) p/x *arKey
$32 = 0x65
(gdb) p/x $rcx
$33 = 0x10088e29e
(gdb) next
258 memcpy((char*)p->arKey, arKey, nKeyLength);
(gdb) p/x arKey
$41 = 0x10088e298
(gdb) print arKey
$42 = 0x10088e298 "engine"
[...]
(gdb) next
262 p->h = h;
(gdb) print arKey
$48 = 0x18 
(gdb) p/x arKey
$49 = 0x18
(gdb) print *p
$51 = {
  h = 0, 
  nKeyLength = 7, 
  pData = 0x100222bf0, 
  pDataPtr = 0x0, 
  pListNext = 0x2, 
  pListLast = 0x60001, 
  pNext = 0x52100010, 
  pLast = 0x0, 
  arKey = 0x100222be8 "engine"
}
[...]
(gdb) next

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x5448523c
0x0001012e9e72 in _zend_hash_add_or_update (ht=0x10087d120, arKey=0x18 
, nKeyLength=7, pData=0x7fff5fbff330, nDataSize=24, 
pDest=0x0, flag=1) at /Users/Grayling/php5.4-201109192030/Zend/zend_hash.c:268
268 HANDLE_BLOCK_INTERRUPTIONS();


[2011-09-20 14:32:07] larue...@php.net

this is so weird, since in the frame #0, the arkey is an invalid pointer, but 
it 
shoud be exactlly same as the name in #1, since I can not reproduce this in my 
environ,  could you do me a favor and try to find out the reason for how could 
this var be damaged?

you can try  to use gdb httpd, make a break point "b real_value_hnd", then exam 
it 
step by step, thanks


[2011-09-20 13:43:29] j dot amend at gmail dot com

I just tried it with php5.4-201109192030 on my Mac (Apache/2.2.17, Mac OS X 
10.6.7) with the same result.

#0  0x0001012e9e72 in _zend_hash_add_or_update (ht=0x10087d118, arKey=0x18 
, nKeyLength=7, pData=0x7fff5fbff350, nDataSize=24, 
pDest=0x0, flag=1) at /Users/Grayling/php5.4-201

Bug #61287 [Asn]: A particular string fails to decompress

[pajoye]

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

 ID: 61287
 Updated by: paj...@php.net
 Reported by:yoozer at gmail dot com
 Summary:A particular string fails to decompress
 Status: Assigned
 Type:   Bug
 Package:Zlib related
-Operating System:   Windows
+Operating System:   *
 PHP Version:5.4.0
 Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

Not win specific, confirmed on other OSes too.


Previous Comments:

[2012-03-05 14:14:50] yoozer at gmail dot com

Description:

We use gzdeflate to compress search parameters. When we recently upgraded from 
5.3.8 to 5.4, a slew of error messages appeared. See the test script below. 
We've tried to minimize it, but any changes do not cause the error to trigger.

Changing the variable name "region_id" to "egion_id" results in 90.
Changing the variable name "region_id" to "tegion_id" causes the same error.
Changing the variable name "discipline" to "isciplined" results in 92.

Changing the value assigned to region_id from 1 to 2 results in 92.
Changing the value assigned to region_id from 1 to 4 results in an error.

Test script:
---
$array = array(
'region_id' => 1,
'discipline' => 23,
'degrees' => array(),
'country_id' => 27
);

$serialized = serialize($array);

$deflated = gzdeflate($serialized, 9);
$inflated = gzinflate($deflated);

echo strlen($inflated);

Expected result:

Expected: 92

Actual result:
--
Warning: gzinflate(): data error in D:\Web\Projects\Bench\index.php on line 13
0






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

Bug #61272 [Nab]: ob_start callback get passed empty string

[peacech at gmail dot com]

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

 ID: 61272
 User updated by:peacech at gmail dot com
 Reported by:peacech at gmail dot com
 Summary:ob_start callback get passed empty string
 Status: Not a bug
 Type:   Bug
 Package:Output Control
 Operating System:   Arch 32 bit
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Unless ob_start callback specification has changed that for 
ob_clean/ob_end_clean, the output is discarded before calling the callback, 
then this is a bug. And I have scan the PHP 5.4 changelog and couldn't find 
anything mentioning this change.

So let me help by showing where the problem is

In line 1226 of output.c in the distributed PHP 5.4.0 source,

if (flags & PHP_OUTPUT_POP_DISCARD) {
context.op |= PHP_OUTPUT_HANDLER_CLEAN;
orphan->buffer.used = 0;
}
php_output_handler_op(orphan, &context);

orphan->buffer.used should not be set to 0 before calling the callback, 
otherwise the callback will be called with empty buffer.

And likewise in line 300 in php_output_clean

So, no, it isn't about appending $output to $buffer.


Previous Comments:

[2012-03-05 11:23:43] m...@php.net

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 should append $output to $buffer.


[2012-03-04 10:53:53] peacech at gmail dot com

Description:

Running test script below with PHP 5.4 outputs

""

Running test script below with PHP 5.3 outputs

"hello"

Test script:
---
https://bugs.php.net/bug.php?id=61272&edit=1

[PHP-BUG] Bug #61287 [NEW]: A particular string fails to decompress

[yoozer at gmail dot com]

From: 
Operating system: Windows
PHP version:  5.4.0
Package:  Zlib related
Bug Type: Bug
Bug description:A particular string fails to decompress

Description:

We use gzdeflate to compress search parameters. When we recently upgraded
from 5.3.8 to 5.4, a slew of error messages appeared. See the test script
below. We've tried to minimize it, but any changes do not cause the error
to trigger.

Changing the variable name "region_id" to "egion_id" results in 90.
Changing the variable name "region_id" to "tegion_id" causes the same
error.
Changing the variable name "discipline" to "isciplined" results in 92.

Changing the value assigned to region_id from 1 to 2 results in 92.
Changing the value assigned to region_id from 1 to 4 results in an error.

Test script:
---
$array = array(
'region_id' => 1,
'discipline' => 23,
'degrees' => array(),
'country_id' => 27
);

$serialized = serialize($array);

$deflated = gzdeflate($serialized, 9);
$inflated = gzinflate($deflated);

echo strlen($inflated);

Expected result:

Expected: 92

Actual result:
--
Warning: gzinflate(): data error in D:\Web\Projects\Bench\index.php on line
13
0

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

[PHP-BUG] Bug #61286 [NEW]: If the trailing path that follows a script contains a dot PATH_INFO is not set

[galacticvoid+php at gmail dot com]

From: 
Operating system: OSX
PHP version:  5.4.0
Package:  Built-in web server
Bug Type: Bug
Bug description:If the trailing path that follows a script contains a dot 
PATH_INFO is not set

Description:

If the trailing path that follows a script contains a dot the variable 
$_SERVER['PATH_INFO'] is not set.

Test script:
---
http://locahost:8000/index.php/not.set

Expected result:

/not.set

Actual result:
--
PHP Notice: Undefined index: PATH_INFO ...

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

Bug #47126 [NoF->ReO]: copy() caches incorrect stat info of file-target

[raphaelm]

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

 ID: 47126
 Updated by: rapha...@php.net
 Reported by:a dot u dot savchuk at gmail dot com
 Summary:copy() caches incorrect stat info of file-target
-Status: No Feedback
+Status: Re-Opened
 Type:   Bug
 Package:Filesystem function related
 Operating System:   linux
 PHP Version:5.2.8
 Block user comment: N
 Private report: N

 New Comment:

Feedback was provided, so although this is not the category I normally work in 
I 
take the liberty to set this bug report to re-opened.


Previous Comments:

[2012-02-28 07:23:27] t dot weber at digi-info dot de

Since the original reporter doesn’t seem to be interested in it anymore, 
I’m 
speaking up.

This bug is still present in PHP 5.3.10.

I agree with the original reporter that the documentation should be updated. 
However, I have not looked into PHP’s source code and cannot comment on his 
proposed solution.


[2009-12-23 01:00:01] 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-12-15 01:03:07] fel...@php.net

Please try using this snapshot:

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

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




[2009-04-09 01:00:01] 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-04-01 11:11:23] j...@php.net

Please try using this CVS snapshot:

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

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






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


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

Bug #60887 [Asn->Csd]: SoapClient ignores user_agent option and sends no User-Agent header

[dmitry]

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

 ID: 60887
 Updated by: dmi...@php.net
 Reported by:mail at tomsommer dot dk
 Summary:SoapClient ignores user_agent option and sends no
 User-Agent header
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SOAP related
 PHP Version:5.3.9
 Assigned To:dmitry
 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-05 12:58:54] dmi...@php.net

Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=323909
Log: Fixed bug #60887 (SoapClient ignores user_agent option and sends no 
User-Agent header)


[2012-01-29 00:55:51] carloschilazo at gmail dot com

After yawk@irc replicated the issue, the problem is that the WSDL request is 
the 
one that is not being sent with the user-agent header set.

Subsequent requests are.

Pending to determine if WSDL request should have user-agent set
 
(replication with screenshots: http://chilldata.com/dev/soapbug/)

Email will be sent to internals mailing list


[2012-01-28 19:16:04] carloschilazo at gmail dot com

Checked it with "User-Agent" and the behavior is the same with and without the 
"-"

Better to be RFC compliant (RFC 2616) and add the '-;, I'll upload the patch 
again.

Thanks!


[2012-01-28 17:41:14] carloschilazo at gmail dot com

This is what I now get after running your script with my patch

Array
(
   [DOCUMENT_ROOT] => /home/chilld/public_html
   [GATEWAY_INTERFACE] => CGI/1.1
   [HTTP_CONNECTION] => close
   [HTTP_HOST] => pfdn.local.chilldata.com
   [HTTP_USER_AGENT] => foo
   [PATH] => /bin:/usr/bin
   [QUERY_STRING] => check=1
   [REDIRECT_STATUS] => 200
   [REMOTE_ADDR] => 189.253.78.75
   [REMOTE_PORT] => 20615
   [REQUEST_METHOD] => GET
   [REQUEST_URI] => /dev/soap.php?check=1
   [SCRIPT_FILENAME] => /home/chilld/public_html/dev/soap.php
   [SCRIPT_NAME] => /dev/soap.php
   [SERVER_ADDR] => 10.34.11.56
   [SERVER_ADMIN] => webmas...@chilldata.com
   [SERVER_NAME] => www.chilldata.com
   [SERVER_PORT] => 80
   [SERVER_PROTOCOL] => HTTP/1.1
   [SERVER_SIGNATURE] =>
   [SERVER_SOFTWARE] => Apache
   [UNIQUE_ID] => TyOIZK3Hp1AAADUKGtYL
   [PHP_SELF] => /dev/soap.php
   [REQUEST_TIME] => 1327728740


   [argv] => Array
   (
   [0] => check=1
   )

   [argc] => 1
)


and if i change to see the $_SERVER['HTTP_USER_AGENT'] variable I get also foo


[2012-01-28 12:31:41] mail at tomsommer dot dk

Regarding your patch, I believe the header is "User-Agent", not "User Agent" :)




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


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

Bug #61285 [Opn]: SSL connections do not timeout

[pajoye]

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

 ID: 61285
 Updated by: paj...@php.net
 Reported by:tony2...@php.net
 Summary:SSL connections do not timeout
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 PHP Version:5.4SVN-2012-03-05 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I am not sure anymore that this patch is correct as it looks as it will 
reintroduce the issue introduced by a previous attempt to fix that, which was 
reverted here:

http://svn.php.net/viewvc?view=revision&revision=315310


Previous Comments:

[2012-03-05 12:08:40] tony2...@php.net

The following patch has been added/updated:

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


[2012-03-05 12:08:11] tony2...@php.net

Description:

SSL connections never timeout because poll() isn't even used in ext/openssl.


Test script:
---
server.php:


client.php:
https://localhost/server.php";)); ?>




Expected result:

# time php client.php

Warning: file_get_contents(https://localhost/server.php): failed to open 
stream: HTTP request failed!  in /tmp/client.php on line 1
bool(false)

real0m2.024s
user0m0.012s
sys 0m0.003s


Actual result:
--
# time php client.php
string(0) ""

real0m20.063s
user0m0.012s
sys 0m0.005s






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

Bug #61285 [PATCH]: SSL connections do not timeout

[tony2...@php.net]

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

 ID: 61285
 Patch added by: tony2...@php.net
 Reported by:tony2...@php.net
 Summary:SSL connections do not timeout
 Status: Open
 Type:   Bug
 Package:OpenSSL related
 PHP Version:5.4SVN-2012-03-05 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

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


Previous Comments:

[2012-03-05 12:08:11] tony2...@php.net

Description:

SSL connections never timeout because poll() isn't even used in ext/openssl.


Test script:
---
server.php:


client.php:
https://localhost/server.php";)); ?>




Expected result:

# time php client.php

Warning: file_get_contents(https://localhost/server.php): failed to open 
stream: HTTP request failed!  in /tmp/client.php on line 1
bool(false)

real0m2.024s
user0m0.012s
sys 0m0.003s


Actual result:
--
# time php client.php
string(0) ""

real0m20.063s
user0m0.012s
sys 0m0.005s






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

[PHP-BUG] Bug #61285 [NEW]: SSL connections do not timeout

[tony2...@php.net]

From: tony2001
Operating system: 
PHP version:  5.4SVN-2012-03-05 (SVN)
Package:  OpenSSL related
Bug Type: Bug
Bug description:SSL connections do not timeout

Description:

SSL connections never timeout because poll() isn't even used in
ext/openssl.


Test script:
---
server.php:


client.php:
https://localhost/server.php";)); ?>




Expected result:

# time php client.php

Warning: file_get_contents(https://localhost/server.php): failed to open
stream: HTTP request failed!  in /tmp/client.php on line 1
bool(false)

real0m2.024s
user0m0.012s
sys 0m0.003s


Actual result:
--
# time php client.php
string(0) ""

real0m20.063s
user0m0.012s
sys 0m0.005s

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

Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI

[florian dot fernandez at navaho dot fr]

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

 ID: 60826
 Comment by: florian dot fernandez at navaho dot fr
 Reported by:clarkwise at gmail dot com
 Summary:raw POST data missing with chunked encoding, FastCGI
 Status: Assigned
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Windows XP
 PHP Version:5.3.9
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

I forgot to mention that this is on a Linux system


Previous Comments:

[2012-03-05 10:08:17] florian dot fernandez at navaho dot fr

Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.

POST datas sent with "Transfer-encoding: chunked" are not received as they 
should be. The raw request looks like this :

POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

3ff4
(here, the datas)
0

and the request as the receiving script sees it :

User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache


As you can see, the request body is empty.

However, this problem does not occur when PHP runs as mod_php under Apache. 
Problem confirmed under PHP 5.3.8 and 5.3.9.

I don't know if that is a PHP bug and maybe the developers could confirm or not 
that the request body are wrong before it reaches PHP. I think that it appears 
to be a mod_fcgid bug and should be reported as one to Apache bug list.


Here are the scripts to reproduce the bug :

sendChunk.php :
 'no-cache',
'Connection' => 'keep-alive',
'Cache-Control' => 'no-cache',
'Content-Length' => strlen($fileContentToUp) ,
'Transfer-Encoding' => 'chunked'
);

$options = array(headers => $header_array);

$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();

echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>

receiveChunk.php :
 '."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>

Hope that helps.


[2012-03-01 20:24:53] clarkwise at gmail dot com

Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the 
opportunity 
to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks.


[2012-03-01 08:31:15] a...@php.net

@clarkwise at gmail dot com

So could you confirm it works with nginx+chunkin?

As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you 
have?


[2012-02-09 19:17:27] a...@php.net

I've additionally tested the two files on nginx with PHP as FCGI. The request 
simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb 
to the PHP and set a break in the accept loop - there was no reaction when 
using the two test files, but requests without data got down to PHP. So my 
conclusion were - apache simply ignores the request body where nginx gives a 
correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and 
Nginx seem to have no implementation for chunked incoming body stuff, but they 
do handle that a different way.

Btw. Nginx has the "chunkin" module for such actions.


[2012-02-02 00:35:42] timo dot witte at googlemail dot com

I have the same problem on my machine and can confirm this bug!
i think this bug affects mod_spdy aswell, because it sends the POST data 
chunked! 
( http://code.google.com/p/mod-spdy/issues/detail?id=22 ).




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


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

Bug #60898 [Com]: Failed to upload files when content-type contain charset

[grzegorz129 at gmail dot com]

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

 ID: 60898
 Comment by: grzegorz129 at gmail dot com
 Reported by:grzegorz129 at gmail dot com
 Summary:Failed to upload files when content-type contain
 charset
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Any news on this annoying bug?


Previous Comments:

[2012-01-27 03:36:24] grzegorz129 at gmail dot com

Description:

When I try to upload files using HTTP post with header "Content-Type: 
multipart/form-data; boundary=-NPRequestBoundary-" everything works as 
expected but trying to use "Content-Type: multipart/form-data; boundary=-
NPRequestBoundary-; charset=UTF-8" cause completely blank $_FILES array.

Expected result:

Full $_FILES array

Actual result:
--
Empty $_FILES array






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

Bug #61272 [Opn->Nab]: ob_start callback get passed empty string

[mike]

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

 ID: 61272
 Updated by: m...@php.net
 Reported by:peacech at gmail dot com
 Summary:ob_start callback get passed empty string
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Output Control
 Operating System:   Arch 32 bit
 PHP Version:5.4.0
 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 should append $output to $buffer.


Previous Comments:

[2012-03-04 10:53:53] peacech at gmail dot com

Description:

Running test script below with PHP 5.4 outputs

""

Running test script below with PHP 5.3 outputs

"hello"

Test script:
---
https://bugs.php.net/bug.php?id=61272&edit=1

Req #61277 [Nab]: Feature request: Shared Keyword

[thbley at gmail dot com]

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

 ID: 61277
 User updated by:thbley at gmail dot com
 Reported by:thbley at gmail dot com
 Summary:Feature request: Shared Keyword
 Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   All
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

Magic methods are nice but checking if the extension is available and enabled, 
maybe compile it before, implement the whole interface, define some good error 
handling, include the library, implement the fallback for non-apc, ... a lot of 
work than could be handled by a one-liner.
People love sth. like session_start(); $_SESSION["hello"] = "world"; without 
knowing all the stuff behind it.


Previous Comments:

[2012-03-05 05:53:56] ras...@php.net

APC will eventually go in, but it is not going to be directly mapped to any 
sort 
of special shared keywords. Like I said, there are plenty of ways to map this 
in 
userspace via the various magic methods.


[2012-03-05 05:44:17] thbley at gmail dot com

I think it shouldn't be a big issue to get a small portion of the apc or 
memcache code in the core and make it stable. In the end of 2005, there was the 
decision to include apc in the core. So I think it is not a bad idea to look at 
this again.


[2012-03-05 03:55:12] ras...@php.net

And APC is still not stable and portable enough to include in PHP, so saying to 
do 
it like APC doesn't mean much. Doing it like APC means not putting it not the 
core. And if you want something just like APC, just use APC. Most of the 
frameworks already do and they include a slower fallback for servers without 
APC.
This is not going to be baked into the object syntax directly since we have all 
the magic methods you need to hook it in yourself.


[2012-03-05 02:26:09] thbley at gmail dot com

> It is a design decision in PHP not to have such global things in PHP itself.

All PHP frameworks are offering some kind of caching with shared disk or shared 
memory. And I haven't seen a bigger project not using this stuff. It's time to 
rethink this decision.

> - correct locking can be hard

I think the way APC does this it, should do it.

> - such a feature makes scaling over multiple servers hard

It would be enough to have it on one server. For those who want more, can still 
send the data to memcache.

Here is a new example: https://gist.github.com/1975954


[2012-03-05 00:19:10] johan...@php.net

It is a design decision in PHP not to have such global things in PHP itself. 
Addon modules (you mentioned apc) can add utilities for this, though.

Some reasons include: 
- PHP can be embedded in any application which might add constrains
- correct locking can be hard
- such a feature makes scaling over multiple servers hard
- it messes with copy-on-write
- ...




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


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

Bug #61246 [Com]: Error when running PHP-FPM

[takida at nm dot ru]

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

 ID: 61246
 Comment by: takida at nm dot ru
 Reported by:osmanungur at gmail dot com
 Summary:Error when running PHP-FPM
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Mac Os X 10.7.3
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

If it would help, apache is running as MPM-Prefork. Everything else is pretty 
standard.


Previous Comments:

[2012-03-05 10:02:18] takida at nm dot ru

I'm experiencing the same bug as the guy with Ubuntu yet on CentOS 5.7 with 
Apache. Same php version, same APC version, almost the same error:
*** glibc detected *** php-fpm: master process (/usr/lib/php-5.4.0-
custom/etc/php-fpm.conf): free(): invalid pointer: 0xb72a1010 ***

What is strange, php-apc was build from source and could not pass the "make 
test" 
step completely. When disabling APC everything is fine, otherwise php doesn't 
work at all.


[2012-03-04 08:05:20] rnysmile at yahoo dot com

similar problem in Ubuntu 10.04

# /etc/init.d/php-fpm restart
Gracefully shutting down php-fpm . done
Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): 
invalid 
pointer: 0x7f78b5d45118 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7f78b2e6d5b6]
/lib/libc.so.6(cfree+0x73)[0x7f78b2e73e83]
/usr/local/sbin/php-fpm(destroy_zend_class+0x23d)[0x73953d]
/usr/local/sbin/php-fpm(zend_hash_clean+0x73)[0x74e7e3]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f78b0285460]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_module_shutdown+0x12a)[0x7f78b027d8fa]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(+0xb07f)
[0x7f78b027407f]
/usr/local/sbin/php-fpm[0x747855]
/usr/local/sbin/php-fpm[0x74e152]
/usr/local/sbin/php-fpm(zend_hash_graceful_reverse_destroy+0x18)[0x74e3e8]
/usr/local/sbin/php-fpm[0x742443]
/usr/local/sbin/php-fpm(php_module_shutdown+0x2d)[0x6e671d]
/usr/local/sbin/php-fpm[0x7f12b9]
/usr/local/sbin/php-fpm[0x7e958e]
/usr/local/sbin/php-fpm[0x7f693a]
/usr/local/sbin/php-fpm[0x7e89c5]
/usr/local/sbin/php-fpm[0x7efb68]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f78b2e14c4d]
/usr/local/sbin/php-fpm[0x42f989]


No error if disable APC.


[2012-03-02 14:54:56] osmanungur at gmail dot com

Description:

Hi,

Today i upgraded my php installation to PHP 5.4, when i running PHP-FPM i'm 
getting this error

➜ sudo php-fpm
php-fpm(20297) malloc: *** error for object 0x10aeb5c00: pointer being freed 
was 
not allocated
*** set a breakpoint in malloc_error_break to debug

FPM still works and responses without problem via Nginx. 
I haven't problem before upgrading PHP (with PHP 5.3.10). I'm running PHP with 
APC 
3.1.9.









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

Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI

[florian dot fernandez at navaho dot fr]

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

 ID: 60826
 Comment by: florian dot fernandez at navaho dot fr
 Reported by:clarkwise at gmail dot com
 Summary:raw POST data missing with chunked encoding, FastCGI
 Status: Assigned
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Windows XP
 PHP Version:5.3.9
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.

POST datas sent with "Transfer-encoding: chunked" are not received as they 
should be. The raw request looks like this :

POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

3ff4
(here, the datas)
0

and the request as the receiving script sees it :

User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache


As you can see, the request body is empty.

However, this problem does not occur when PHP runs as mod_php under Apache. 
Problem confirmed under PHP 5.3.8 and 5.3.9.

I don't know if that is a PHP bug and maybe the developers could confirm or not 
that the request body are wrong before it reaches PHP. I think that it appears 
to be a mod_fcgid bug and should be reported as one to Apache bug list.


Here are the scripts to reproduce the bug :

sendChunk.php :
 'no-cache',
'Connection' => 'keep-alive',
'Cache-Control' => 'no-cache',
'Content-Length' => strlen($fileContentToUp) ,
'Transfer-Encoding' => 'chunked'
);

$options = array(headers => $header_array);

$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();

echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>

receiveChunk.php :
 '."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>

Hope that helps.


Previous Comments:

[2012-03-01 20:24:53] clarkwise at gmail dot com

Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the 
opportunity 
to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks.


[2012-03-01 08:31:15] a...@php.net

@clarkwise at gmail dot com

So could you confirm it works with nginx+chunkin?

As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you 
have?


[2012-02-09 19:17:27] a...@php.net

I've additionally tested the two files on nginx with PHP as FCGI. The request 
simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb 
to the PHP and set a break in the accept loop - there was no reaction when 
using the two test files, but requests without data got down to PHP. So my 
conclusion were - apache simply ignores the request body where nginx gives a 
correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and 
Nginx seem to have no implementation for chunked incoming body stuff, but they 
do handle that a different way.

Btw. Nginx has the "chunkin" module for such actions.


[2012-02-02 00:35:42] timo dot witte at googlemail dot com

I have the same problem on my machine and can confirm this bug!
i think this bug affects mod_spdy aswell, because it sends the POST data 
chunked! 
( http://code.google.com/p/mod-spdy/issues/detail?id=22 ).


[2012-01-20 21:15:54] clarkwise at gmail dot com

Description:

When a POST is sent with the header "Transfer-Encoding: chunked" and PHP 5.3 is 
running via FastCGI, $HTTP_RAW_POST_DATA is not set. In IIS, the receiving PHP 
process simply hangs and does not execute at all. If chunked encoding is not 
set, 
it executes successfully and $HTTP_RAW_POST_DATA is populated.

Comparing ISAPI to FastCGI (using PHP 5.2 which has both implementations), PHP 
ISAPI works fine with "Transfer-Encoding: chunked" but PHP FastCGI does not.

This issue also occurred running Linux/Apache with PHP 5.3 FastCGI. In that 
scenario, the PHP process did not completely hang, but $HTTP_RAW_POST_DATA and 
php://input were empty when the script executed.

Test script:
---
Two files, postsend.php and postreceive.php, can be found within t

Bug #61246 [Com]: Error when running PHP-FPM

[takida at nm dot ru]

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

 ID: 61246
 Comment by: takida at nm dot ru
 Reported by:osmanungur at gmail dot com
 Summary:Error when running PHP-FPM
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Mac Os X 10.7.3
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I'm experiencing the same bug as the guy with Ubuntu yet on CentOS 5.7 with 
Apache. Same php version, same APC version, almost the same error:
*** glibc detected *** php-fpm: master process (/usr/lib/php-5.4.0-
custom/etc/php-fpm.conf): free(): invalid pointer: 0xb72a1010 ***

What is strange, php-apc was build from source and could not pass the "make 
test" 
step completely. When disabling APC everything is fine, otherwise php doesn't 
work at all.


Previous Comments:

[2012-03-04 08:05:20] rnysmile at yahoo dot com

similar problem in Ubuntu 10.04

# /etc/init.d/php-fpm restart
Gracefully shutting down php-fpm . done
Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: free(): 
invalid 
pointer: 0x7f78b5d45118 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7f78b2e6d5b6]
/lib/libc.so.6(cfree+0x73)[0x7f78b2e73e83]
/usr/local/sbin/php-fpm(destroy_zend_class+0x23d)[0x73953d]
/usr/local/sbin/php-fpm(zend_hash_clean+0x73)[0x74e7e3]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f78b0285460]
/usr/local/lib/php/extensions/no-debug-non-zts-
20100525/apc.so(apc_module_shutdown+0x12a)[0x7f78b027d8fa]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(+0xb07f)
[0x7f78b027407f]
/usr/local/sbin/php-fpm[0x747855]
/usr/local/sbin/php-fpm[0x74e152]
/usr/local/sbin/php-fpm(zend_hash_graceful_reverse_destroy+0x18)[0x74e3e8]
/usr/local/sbin/php-fpm[0x742443]
/usr/local/sbin/php-fpm(php_module_shutdown+0x2d)[0x6e671d]
/usr/local/sbin/php-fpm[0x7f12b9]
/usr/local/sbin/php-fpm[0x7e958e]
/usr/local/sbin/php-fpm[0x7f693a]
/usr/local/sbin/php-fpm[0x7e89c5]
/usr/local/sbin/php-fpm[0x7efb68]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f78b2e14c4d]
/usr/local/sbin/php-fpm[0x42f989]


No error if disable APC.


[2012-03-02 14:54:56] osmanungur at gmail dot com

Description:

Hi,

Today i upgraded my php installation to PHP 5.4, when i running PHP-FPM i'm 
getting this error

➜ sudo php-fpm
php-fpm(20297) malloc: *** error for object 0x10aeb5c00: pointer being freed 
was 
not allocated
*** set a breakpoint in malloc_error_break to debug

FPM still works and responses without problem via Nginx. 
I haven't problem before upgrading PHP (with PHP 5.3.10). I'm running PHP with 
APC 
3.1.9.









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

Bug #47133 [Com]: php-odbc SQLBindCol() not used correctly

[crypteo at gmail dot com]

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

 ID: 47133
 Comment by: crypteo at gmail dot com
 Reported by:marquis at us dot ibm dot com
 Summary:php-odbc SQLBindCol() not used correctly
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   Fedora 9
 PHP Version:5.2.8
 Block user comment: N
 Private report: N

 New Comment:

This is still happening with php 5.3.10


Previous Comments:

[2009-01-17 00:13:11] marquis at us dot ibm dot com

Description:

PHP applications that use the iSeries Access for Linux ODBC driver to SELECT 
CHAR data containing characters outside the invariant character set (for 
example: "ü"), and using a UTF-8 locale, may receive extra garbage data at the 
end of the character string.
This is caused by PHP passing an insufficient target length on the call to 
SQLBindCol(). PHP is setting the incorrect buffer length by using 
SQLColAttributes to return the SQL_COLUMN_DISPLAY_SIZE.

I have seen this behavior on PHP 5.1 and 5.2.6-2
This problem also exists in PHP for Windows.

The iSeries Access for Linux ODBC driver correctly returns error message :
CWB0111 - A buffer passed to a system call is too small to hold return data

However, the ODBC driver will be changed to not return the extra garbage data 
at the end of the CHAR string when using a connection string keyword option.
PHP applications could then ignore the CWB0111 error message.

For PHP applications using the UTF8 locale to use this workaround and prevent 
the extra garbage data, the odbc connection must pass in the following 
connection string keyword:  
DEBUG = 65536

Additional options:
PHP does not calculate all buffer lengths using SQL_COLUMN_DISPLAY SIZE, so, 
PHP developers could use other SQL column types such as: 
SQL_BINARY, SQL_VARBINARY, SQL_LONGVARBINARY or SQL_LONGVARCHAR. No binding 
occurs with those data types and SQLGetData() is used to retrieve the value.
For long data it may be neccessary to call PHP ODBC API odbc_longread() 
(http://us3.php.net/odbc_longreadlen) , because that is the length to be used 
for the buffer. If less data is available, PHP shrinks the buffer, but if more 
data is available, truncation will occur.

Ref IBM APAR SE33393
http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/SE33393

The ideal solution would be for PHP to use the correct buffer length on the 
call to SQLBindCol().

Reproduce code:
---
#!/usr/bin/php


Expected result:

Just return the CHAR string without extra data at the end.
For example:

array(1) {
  ["AFIELD"]=>
  string(6) "ü   "
}

Actual result:
--
array(1) {
  ["AFIELD"]=>
  string(40) "ü   "
}






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

Bug #51672 [Nab->Csd]: Parse error when a subscript operator is used after a function call operator

[stas]

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

 ID: 51672
 Updated by: s...@php.net
 Reported by:miklcct at gmail dot com
 Summary:Parse error when a subscript operator is used after
 a function call operator
-Status: Not a bug
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Ubuntu 9.04
 PHP Version:5.3.2
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

This syntax is now part of PHP 5.4.


Previous Comments:

[2011-08-26 09:56:49] nmn at mailinator dot com

Not a bug, just a stupid feature that demonstrate the lack of vision in the 
language design.


[2010-04-27 12:14:50] degeb...@php.net

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.




[2010-04-27 12:11:21] miklcct at gmail dot com

Description:

syntax error when a subscript operator is used with a function call operator

Test script:
---
#!/usr/bin/php

https://bugs.php.net/bug.php?id=51672&edit=1

Req #32177 [Com]: ReflectionException

[daanleduc at hotmail dot com]

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

 ID: 32177
 Comment by: daanleduc at hotmail dot com
 Reported by:pawel dot kozlowski at gmail dot com
 Summary:ReflectionException
 Status: Assigned
 Type:   Feature/Change Request
 Package:Reflection related
 Operating System:   Any
 PHP Version:5.0.3
 Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

Had the same problem fixed it like this ->

http://stackoverflow.com/questions/4513867/php-reflection-get-method-parameter-
type-as-string/9500359#9500359

Would be better if there is an getClassName on reflection parameter.


Previous Comments:

[2005-03-03 16:29:24] pawel dot kozlowski at gmail dot com

Description:

I’m trying to use Reflection API. I works great, but I’ve some remarks 
regarding ReflectionException. Calling ReflectionParameter::getClass() will 
raise an exception when class definition isn’t already included. That’s fine, 
it’s an expected behavior. The problem is that I have no way to get the missing 
class name. Ok, I could parse message string, but this way it becomes 
(unintentionally) part of  the public API. What do You think about having sth 
like

Class ReflectionExceptionClassNotDefined extends ReflectionException
{
public string getClassName();

}


Reproduce code:
---
class A
{
public function __construct(B $b)
{
   $this->b = $b;
}
}

$rc = new ReflectionClass('A');
$rconstr = $rc->getConstructor();
$rparams = $rconstr->getParameters();

try
{
   $paramclass = $rparams[0]->getClass();
}
catch (ReflectionException $e)
{
   //no way to get 'B' name here, without parsing msg string
}







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

Req #60432 [Com]: Improving typehinting in function args

[daanleduc at hotmail dot com]

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

 ID: 60432
 Comment by: daanleduc at hotmail dot com
 Reported by:duke at ejoom dot com
 Summary:Improving typehinting in function args
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.4.0RC2
 Block user comment: N
 Private report: N

 New Comment:

Would be also nice if its possible to add an more strict mode for functions.
For example ->

function test(int $int, string $string, float $float) {}

behavior -> 

function('test', 12, "blaat") {} <-- shouldn't throw

ini_set('function_strict', true);
function('test', 12, "blaat") {} <-- should throw

It should be really strict so if its not an int it is not valid (triple === 
check). Even if its an int string ("1").

What duke suggest is nice but still breaks if you do an bool (true) in an int, 
its casts safely to int 1. Should just throw if you put the strict mode on or 
maybe build some levels of strict mode.

It would save me and a lot of other developers all the sanity checks.


Previous Comments:

[2011-12-02 21:26:12] duke at ejoom dot com

It can be possible to use the function to delete rows in DB:
function delete( array $ids ) { //some code}

delete(3); //will work correct as expected.
// Or
delete(array(3,6));// will work.


Or we would be able to use that behaviour: 
$object->property1 = 1;
$object->property2 = 'value';
tipehind($object);
//where $object converting into array.


[2011-12-02 21:12:43] duke at ejoom dot com

Description:

I want to discuss an improving typehint.

I propose to do typehint behaviour as following:
On the Object instance it will behave as current (emit an error).
At the array int and float it must do equivalence:

function typehint( array $array, string $string, int $int, float $float )
{}
   will be equivalent to
function typehint( $array, $string, $int, $float )
{
if (is_array($array) === false) $array = (array) $array;
$string = (string) $string;
$int = (int) $int;
$float = (float) $float;
}

It will do code more readable and compact. For Zend Framework DB it will do 
easier typing query where escaping is based on type of var,

Isn't logical emit error on mismatching of type on int and string at PHP caused 
by easing change type against C or C++. So we must use it feature of PHP and do 
life easier ;).







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