Req #61004 [Wfx]: Add mysql_safe_query

2012-02-10 Thread pazzo at bahnhof dot se
Edit report at https://bugs.php.net/bug.php?id=61004&edit=1

 ID: 61004
 User updated by:pazzo at bahnhof dot se
 Reported by:pazzo at bahnhof dot se
 Summary:Add mysql_safe_query
 Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Are you seriously telling me that PHP created a new MySQL interface without 
dealing with the bad design of the queries?


Previous Comments:

[2012-02-09 00:29:35] ahar...@php.net

ext/mysql is deprecated in PHP 5.4 (albeit without actual PHP warnings until 
PHP 
5.5). Migrating to mysqli or PDO is strongly recommended at this time, and the 
legacy MySQL extension won't be receiving new features.


[2012-02-08 21:59:43] phpmpan at mpan dot pl

Since people rarely refresh their knowledge, even when they know it's old, 
those links may help realizing that for at least few years there are newer and 
more secure solutions than old mysql extension:
- http://www.php.net/manual/en/book.pdo.php
- http://www.php.net/manual/en/book.mysqli.php


[2012-02-07 15:03:13] pazzo at bahnhof dot se

Description:

Since people are bad at securing their code, even when they know how, this 
function may give securer and more readable code:

mysql_safe_query('UPDATE people SET (name, number) VALUES ? WHERE name = ? or 
?` 
= ?',
 array('new name', 5553475), 'old name', 'custom field', 5);


I've provided an example of how to solve this using php code.

Test script:
---
http://pastebin.com/8EcS9y1B







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


Bug #61037 [Opn->Nab]: Cookie Name Changing

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

 ID: 61037
 Updated by: larue...@php.net
 Reported by:anoop_alex at yahoo dot com
 Summary:Cookie Name Changing
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Apache related
 Operating System:   Windows 7 Prof
 PHP Version:5.3SVN-2012-02-10 (SVN)
 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

Dots and spaces in variable names are converted to underscores. For example 
 becomes $_REQUEST["a_b"].

http://php.net/manual/en/language.variables.external.php


Previous Comments:

[2012-02-10 06:50:35] anoop_alex at yahoo dot com

Description:

My application supports user IDs with underscore or dot between alphanumeric 
string. The users preferences are stored in cookies. The cookie key is prefixed 
with the user id. It is observed that the dots in the userIDs are getting 
converted to underscores in the setCookie method. The same replacement doesn't 
appear to happen during retrieve and hence the application fails to detect the 
preferences.

Sample Script:


Output
Array ( [test_cookie_error] => something ) 

Test script:
---




Expected result:

Array ( [test.cookie.error] => something )



Actual result:
--
Array ( [test_cookie_error] => something )






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


Bug #42281 [Com]: ldap_get_option > LDAP_OPT_SERVER_CONTROLS > doesnt work

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

 ID: 42281
 Comment by: jeffreydwalter at gmail dot com
 Reported by:comet at ourplanet dot at
 Summary:ldap_get_option > LDAP_OPT_SERVER_CONTROLS > doesnt
 work
 Status: Not a bug
 Type:   Bug
 Package:LDAP related
 Operating System:   Windows XP
 PHP Version:5.2.4RC1
 Block user comment: N
 Private report: N

 New Comment:

Is this every going to be addressed? Does it work now?


Previous Comments:

[2007-08-13 20:05:55] comet at ourplanet dot at

Ok, fine, 
any clue when this feature will be implemented ?


[2007-08-13 16:52:06] j...@php.net

Of course not, that option is not implemented. (there is already feature 
request for it)


[2007-08-13 07:27:57] comet at ourplanet dot at

Description:

ldap_get_option( $this->connection, LDAP_OPT_SERVER_CONTROLS, &$returnValue ); 

returns no value !







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


Bug #39588 [Com]: unpack("a*", "abc\0") does not work as expected

2012-02-10 Thread su dot hang at yahoo dot com
Edit report at https://bugs.php.net/bug.php?id=39588&edit=1

 ID: 39588
 Comment by: su dot hang at yahoo dot com
 Reported by:pprasse at actindo dot de
 Summary:unpack("a*", "abc\0") does not work as expected
 Status: Not a bug
 Type:   Bug
 Package:Strings related
 Operating System:   linux 2.6.10
 PHP Version:4.4.4
 Block user comment: N
 Private report: N

 New Comment:

is this also expected behavior?


  string(3) "str"
}


Previous Comments:

[2006-11-22 14:23:04] tony2...@php.net

Expected behaviour.

$var = "str";
$packed = pack("a5", $var); // 5 bytes long NULL-padded string
var_dump(unpack("a*", $packed)); // the NULL-padding is removed to get the 
original data.


[2006-11-22 14:09:26] pprasse at actindo dot de

Description:

unpack( "a*", $string ) does not work as expected when last character of 
$string is "\0"


Reproduce code:
---


Expected result:

strlen = 4
hex dump:61 62 63 00


Actual result:
--
strlen = 3
hex dump:61 62 63







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


[PHP-BUG] Bug #61038 [NEW]: unpack("a5", "str\0") does not work as expected

2012-02-10 Thread su dot hang at yahoo dot com
From: 
Operating system: Linux (3.0.0-15-generic)
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:unpack("a5", "str\0") does not work as expected

Description:

related bug: https://bugs.php.net/bug.php?id=39588

if unpacking from a binary string ending with any number of "\0"'s, and the
unpack string length is given, the resulted string does not have the right
length. 

for example, unpack("a5", "str\0") should result in a 5-byte-long string,
but it returns a 3-byte-long instead. 

Test script:
---

  string(5) "str\0\0"
}

Actual result:
--
array(1) {
  [1]=>
  string(3) "str"
}

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



Bug #61009 [Nab]: max_input_vars

2012-02-10 Thread j dot hensoldt at gmx dot de
Edit report at https://bugs.php.net/bug.php?id=61009&edit=1

 ID: 61009
 User updated by:j dot hensoldt at gmx dot de
 Reported by:j dot hensoldt at gmx dot de
 Summary:max_input_vars
 Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Debian squeeze
 PHP Version:5.3SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

SOLVED :-)

It was suhosin. The parameters:

suhosin.get.max_vars
suhosin.post.max_vars 
suhosin.request.max_vars

overwrite max_input_vars in php.ini.
That´s confused.


Previous Comments:

[2012-02-08 13:37:04] j dot hensoldt at gmx dot de

ok, max_input_vars cant´t be set using ini_set().  I did not know that - 
thanks.

But i cant´t set max_input_vars in php.ini too. phpinfo() displays the 
correctly changed value (for example max_input_vars=5000), but the 
array-input-variables with index > 1000 are truncated. (sorry for my english, i 
hope you can understand me)


[2012-02-08 13:14:26] ahar...@php.net

As http://au2.php.net/manual/en/info.configuration.php says, max_input_vars is 
PHP_INI_PERDIR, so can't be set with ini_set().


[2012-02-08 13:00:06] j dot hensoldt at gmx dot de

Description:

I am using PHP 5.3.3-7+squeeze7 on Debian+Apache2.

I cann´t change the parameter max_input_vars.



A change of max_input_vars in php.ini does not work too. phpinfo() displays the 
correctly changed value, but the internal value of max_input_vars is not 
changed and is always 1000.








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


[PHP-BUG] Req #61040 [NEW]: PDOException::getCode() returns SQLSTATE instead of error code

2012-02-10 Thread jjgmeijer at hotmail dot com
From: 
Operating system: Linux
PHP version:  5.3SVN-2012-02-10 (SVN)
Package:  PDO related
Bug Type: Feature/Change Request
Bug description:PDOException::getCode() returns SQLSTATE instead of error code

Description:

PDOException::getCode() returns the SQLSTATE instead of the error code.

For example a var_dump of a random PDOException:

object(PDOException)[97]
  protected 'message' => string 'SQLSTATE[40001]: Serialization failure:
1213 
Deadlock found when trying to get lock; try restarting transaction'
(length=111)
  private 'string' (Exception) => string '' (length=0)
  protected 'code' => string '40001' (length=5)

then the 'code' should not be the SQLSTATE (40001) but the error code
(1213). My 
reason for this is that the SQLSTATE may not be unique, the error code is.

For more info:
http://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html

Test script:
---
Try to get a random PDOException with an invalid query.


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



[PHP-BUG] Bug #61042 [NEW]: unserialize issue

2012-02-10 Thread vigano dot n at clxeurope dot com
From: 
Operating system: Linux Centos
PHP version:  5.3.10
Package:  Arrays related
Bug Type: Bug
Bug description:unserialize issue

Description:

It seems that, using PHP 5.3.9/10, an unserialized object is not properly
cast to array. 


Test script:
---
The following code gives different results using PHP 5.3.8 and PHP
5.3.9/10:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns[0]));



Expected result:

Using PHP 5.3.8:

array(1) { [0]=> string(5) "value" } bool(true)


Actual result:
--
Using PHP 5.3.9/10:

array(1) { ["0"]=> string(5) "value" } bool(false)

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



Bug #61042 [Opn->Dup]: unserialize issue

2012-02-10 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=61042&edit=1

 ID: 61042
 Updated by: cataphr...@php.net
 Reported by:vigano dot n at clxeurope dot com
 Summary:unserialize issue
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux Centos
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

The bug is not in unserialize; the object is correctly unserialized, with the 
rule that objects only have string properties correctly enforced (this was not 
enforced before 5.3.9 though: see bug #55798). The problem is that these 
strings are not converted to numbers when casting to an array. This is a known 
problem and unfortunately the main opinion seems to be this ought not to be 
fixed due to performance issues.


Previous Comments:

[2012-02-10 11:47:47] vigano dot n at clxeurope dot com

Description:

It seems that, using PHP 5.3.9/10, an unserialized object is not properly cast 
to array. 


Test script:
---
The following code gives different results using PHP 5.3.8 and PHP 5.3.9/10:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns[0]));



Expected result:

Using PHP 5.3.8:

array(1) { [0]=> string(5) "value" } bool(true)


Actual result:
--
Using PHP 5.3.9/10:

array(1) { ["0"]=> string(5) "value" } bool(false)






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


Bug #61042 [Com]: unserialize issue

2012-02-10 Thread vigano dot n at clxeurope dot com
Edit report at https://bugs.php.net/bug.php?id=61042&edit=1

 ID: 61042
 Comment by: vigano dot n at clxeurope dot com
 Reported by:vigano dot n at clxeurope dot com
 Summary:unserialize issue
 Status: Duplicate
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux Centos
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Anyway the problem affects only unserialized and cast objects. 
The following code works properly also with PHP 5.3.9/10:

$arr1 = array("0" => "string");
var_dump(isset($arr1["0"]));
var_dump(isset($arr1[0]));

returning:

bool(true) bool(true)


Previous Comments:

[2012-02-10 12:01:19] cataphr...@php.net

The bug is not in unserialize; the object is correctly unserialized, with the 
rule that objects only have string properties correctly enforced (this was not 
enforced before 5.3.9 though: see bug #55798). The problem is that these 
strings are not converted to numbers when casting to an array. This is a known 
problem and unfortunately the main opinion seems to be this ought not to be 
fixed due to performance issues.


[2012-02-10 11:47:47] vigano dot n at clxeurope dot com

Description:

It seems that, using PHP 5.3.9/10, an unserialized object is not properly cast 
to array. 


Test script:
---
The following code gives different results using PHP 5.3.8 and PHP 5.3.9/10:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns[0]));



Expected result:

Using PHP 5.3.8:

array(1) { [0]=> string(5) "value" } bool(true)


Actual result:
--
Using PHP 5.3.9/10:

array(1) { ["0"]=> string(5) "value" } bool(false)






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


Bug #61042 [Com]: unserialize issue

2012-02-10 Thread vigano dot n at clxeurope dot com
Edit report at https://bugs.php.net/bug.php?id=61042&edit=1

 ID: 61042
 Comment by: vigano dot n at clxeurope dot com
 Reported by:vigano dot n at clxeurope dot com
 Summary:unserialize issue
 Status: Duplicate
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux Centos
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

In addition, to be honest I don't believe hat this problem "is that these 
strings are not converted to numbers when casting to an array". 

The following code, where conversion is not required, doesn't work as well:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns["0"]));

result:
array(1) { ["0"]=> string(5) "value" } bool(false)


Previous Comments:

[2012-02-10 12:14:09] vigano dot n at clxeurope dot com

Anyway the problem affects only unserialized and cast objects. 
The following code works properly also with PHP 5.3.9/10:

$arr1 = array("0" => "string");
var_dump(isset($arr1["0"]));
var_dump(isset($arr1[0]));

returning:

bool(true) bool(true)


[2012-02-10 12:01:19] cataphr...@php.net

The bug is not in unserialize; the object is correctly unserialized, with the 
rule that objects only have string properties correctly enforced (this was not 
enforced before 5.3.9 though: see bug #55798). The problem is that these 
strings are not converted to numbers when casting to an array. This is a known 
problem and unfortunately the main opinion seems to be this ought not to be 
fixed due to performance issues.


[2012-02-10 11:47:47] vigano dot n at clxeurope dot com

Description:

It seems that, using PHP 5.3.9/10, an unserialized object is not properly cast 
to array. 


Test script:
---
The following code gives different results using PHP 5.3.8 and PHP 5.3.9/10:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns[0]));



Expected result:

Using PHP 5.3.8:

array(1) { [0]=> string(5) "value" } bool(true)


Actual result:
--
Using PHP 5.3.9/10:

array(1) { ["0"]=> string(5) "value" } bool(false)






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


[PHP-BUG] Bug #61043 [NEW]: Regression in magic_quotes_gpc fix (CVE-2012-0831)

2012-02-10 Thread ond...@php.net
From: ondrej
Operating system: 
PHP version:  5.3SVN-2012-02-10 (SVN)
Package:  Variables related
Bug Type: Bug
Bug description:Regression in magic_quotes_gpc fix (CVE-2012-0831)

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



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

2012-02-10 Thread ond...@php.net
Edit report at https://bugs.php.net/bug.php?id=61043&edit=1

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

 New Comment:

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


Previous Comments:

[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


Bug #61042 [Com]: unserialize issue

2012-02-10 Thread vigano dot n at clxeurope dot com
Edit report at https://bugs.php.net/bug.php?id=61042&edit=1

 ID: 61042
 Comment by: vigano dot n at clxeurope dot com
 Reported by:vigano dot n at clxeurope dot com
 Summary:unserialize issue
 Status: Duplicate
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux Centos
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

A possible workaround is serializing and unserializing again. Look at this 
piece of code:
$arr = (object)array("value0", "value1");
$uns = unserialize(serialize((array)unserialize(serialize($arr;
var_dump($uns);
var_dump(isset($uns["0"]));
var_dump(isset($uns[0]));
var_dump(isset($uns["1"]));
var_dump(isset($uns[1]));

The result is:
array(2) { [0]=> string(6) "value0" [1]=> string(6) "value1" } bool(true) 
bool(true) bool(true) bool(true) 

This definitively confirm my idea that bug #55798 has nothing to do with this 
issue.


Previous Comments:

[2012-02-10 12:22:19] vigano dot n at clxeurope dot com

In addition, to be honest I don't believe hat this problem "is that these 
strings are not converted to numbers when casting to an array". 

The following code, where conversion is not required, doesn't work as well:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns["0"]));

result:
array(1) { ["0"]=> string(5) "value" } bool(false)


[2012-02-10 12:14:09] vigano dot n at clxeurope dot com

Anyway the problem affects only unserialized and cast objects. 
The following code works properly also with PHP 5.3.9/10:

$arr1 = array("0" => "string");
var_dump(isset($arr1["0"]));
var_dump(isset($arr1[0]));

returning:

bool(true) bool(true)


[2012-02-10 12:01:19] cataphr...@php.net

The bug is not in unserialize; the object is correctly unserialized, with the 
rule that objects only have string properties correctly enforced (this was not 
enforced before 5.3.9 though: see bug #55798). The problem is that these 
strings are not converted to numbers when casting to an array. This is a known 
problem and unfortunately the main opinion seems to be this ought not to be 
fixed due to performance issues.


[2012-02-10 11:47:47] vigano dot n at clxeurope dot com

Description:

It seems that, using PHP 5.3.9/10, an unserialized object is not properly cast 
to array. 


Test script:
---
The following code gives different results using PHP 5.3.8 and PHP 5.3.9/10:

$arr = (object)array("value");
$uns = (array)unserialize(serialize($arr));
var_dump($uns);
var_dump(isset($uns[0]));



Expected result:

Using PHP 5.3.8:

array(1) { [0]=> string(5) "value" } bool(true)


Actual result:
--
Using PHP 5.3.9/10:

array(1) { ["0"]=> string(5) "value" } bool(false)






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


[PHP-BUG] Bug #61044 [NEW]: invalid PHP_BINDIR

2012-02-10 Thread bugzilla33 at gmail dot com
From: 
Operating system: win 7
PHP version:  5.4.0RC7
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:invalid PHP_BINDIR

Description:

Install php in folder c:\Php5
As module apache

Test script:
---


Expected result:

c:\Php5

Actual result:
--
c:\Php

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



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

2012-02-10 Thread ond...@php.net
Edit report at https://bugs.php.net/bug.php?id=61043&edit=1

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

 New Comment:

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) ""


Previous Comments:

[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 #61045 [NEW]: fpm don't send error log to fastcgi clients(nginx)

2012-02-10 Thread lxlight at gmail dot com
From: 
Operating system: Linux
PHP version:  5.3.10
Package:  FPM related
Bug Type: Bug
Bug description:fpm don't send error log to fastcgi clients(nginx)

Description:

Since php 5.3.9 released with any variation of config parameters php-fpm
don't send php script errors/warnings to nginx. Reading logs on one
frontend which contains get request, referrer, backend host is very simply.
Pleas add the ability to send stderr to frontend when error_log is
undefined.


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



Bug #42281 [Nab]: ldap_get_option > LDAP_OPT_SERVER_CONTROLS > doesnt work

2012-02-10 Thread comet at ourplanet dot at
Edit report at https://bugs.php.net/bug.php?id=42281&edit=1

 ID: 42281
 User updated by:comet at ourplanet dot at
 Reported by:comet at ourplanet dot at
 Summary:ldap_get_option > LDAP_OPT_SERVER_CONTROLS > doesnt
 work
 Status: Not a bug
 Type:   Bug
 Package:LDAP related
 Operating System:   Windows XP
 PHP Version:5.2.4RC1
 Block user comment: N
 Private report: N

 New Comment:

Wow, I cannot even remember why I required that and how I have finally bypassed 
it 
:-)


Previous Comments:

[2012-02-10 07:56:09] jeffreydwalter at gmail dot com

Is this every going to be addressed? Does it work now?


[2007-08-13 20:05:55] comet at ourplanet dot at

Ok, fine, 
any clue when this feature will be implemented ?


[2007-08-13 16:52:06] j...@php.net

Of course not, that option is not implemented. (there is already feature 
request for it)


[2007-08-13 07:27:57] comet at ourplanet dot at

Description:

ldap_get_option( $this->connection, LDAP_OPT_SERVER_CONTROLS, &$returnValue ); 

returns no value !







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


Bug #60576 [Com]: PHP cURL crash connecting to IIS6 website with NTLM authentication

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

 ID: 60576
 Comment by: jammitch at gmail dot com
 Reported by:cf at infomantis dot de
 Summary:PHP cURL crash connecting to IIS6 website with NTLM
 authentication
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Windows Server 2003/XP/7 (32/64)
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

This appears to be fixed in PHP 5.3.10.


Previous Comments:

[2012-01-13 17:31:54] jammitch at gmail dot com

I am able to reproduce this bug, or something incredibly similar, on IIS 7 and 
7.5, using an out-of-the-box install of WordPress 5.3.8. The cURL jobs trigger 
every minute or so, so that's one page that crashes each minute.

And I'm not the only one:

http://stackoverflow.com/questions/8798286/php-5-3-8-wordpress-curl-intermittent-error

Unfortunately, using cURL from PHP 5.3.6 won't work, as I need the cainfo 
parameter in php.ini to set a root certificate, as the WordPress install is 
behind SSL. I may end up having to do it in code until this is fixed.


[2011-12-20 15:24:05] cf at infomantis dot de

Description:

If one connects to an IIS 6 website configured with "Windows Authentication"
without the correct authentication credentials and authentication type set one 
would expect the PHP code (see sample code) to return the HTTP status code 401 
and exit normally.
This is the behaviour as seen with PHP 5.3.6. For the version 5.3.7/5.3.8 (and 
also tested with the snapshot 5.3 r321148) the PHP process crashes with an 
access violation (see backtrace). Only if correct authentication credentials 
are given and the cURL option CURLOPT_HTTPAUTH is set to CURLAUTH_NTLM 
(CURLAUTH_ANY or CURLAUTH_ANYSAFE will not work!) the script terminates 
successfully and returns the content of the then authenticated request. 
The behaviour is not limited to requests to localhost (as in the sample code) 
and a request to an IIS 7 website with "Windows Authentication" will show the 
expected result (status 401 - no access violation). 

Test script:
---
http://localhost";);
curl_setopt($curl, CURLOPT_VERBOSE, true);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
// if the authentication information are not given 
// in exactly this way the process will crash with 
// an access violation.
//curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_NTLM);
//curl_setopt($curl, CURLOPT_USERPWD, '/:');
$data = curl_exec($curl);
if(curl_errno($curl)) {
   echo 'cURL error: ' . curl_error($curl)."\n";
}
curl_close($curl);

Expected result:

* About to connect() to localhost port 80 (#0)
*   Trying 127.0.0.1... * connected
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
Host: localhost
Accept: */*

< HTTP/1.1 401 Unauthorized
< Content-Length: 1656
< Content-Type: text/html
< Server: Microsoft-IIS/6.0
< WWW-Authenticate: Negotiate
< WWW-Authenticate: NTLM
< Date: Tue, 20 Dec 2011 15:17:01 GMT
<
* Connection #0 to host localhost left intact
* Closing connection #0

Actual result:
--
hread 0 - System ID 836
Entry point   php!mainCRTStartup 
Create time   20.12.2011 15:59:09 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.62 

.NET Call Stack

Full Call Stack

Function Arg 1 Arg 2 Arg 3   Source 
wow64!Wow64NotifyDebugger+9 6b0064f2  
wow64!Wow64KiRaiseException+172 6b006866  0140d730
wow64!Wow64SystemServiceEx+d6 78b83c7d  
wow64cpu!ServiceNoTurbo+28 6b006a5a  7efdf000
wow64!RunCpuSimulation+a 6b005e0d  
wow64!Wow64LdrpInitialize+2ed 77ed7a00  00c0f710
ntdll!LdrpInitializeProcess+1558 77ed519f  
ntdll!LdrpInitialize+18f 77ef2af5  
ntdll!KiUserApcDispatcher+15   
0x77d59680   


Exception Information
PHP_CURL!CURL_INPUT_NEGOTIATE+104In 
php__PID__2880__Date__12_20_2011__Time_04_02_22PM__536__Second_Chance_Exception_C005.dmp
 
the assembly instruction at 
php_curl!Curl_input_negotiate+104 in 
C:\home\PHP\php-5.3-nts-windows-vc9-x86-r321148\ext\php_curl.dll from The PHP 
Group 
has caused an access violation exception (0xC005) when trying to read from 
memory 
location 0x0044 on thread 0






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


Bug #61038 [Opn->Nab]: unpack("a5", "str\0") does not work as expected

2012-02-10 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=61038&edit=1

 ID: 61038
 Updated by: cataphr...@php.net
 Reported by:su dot hang at yahoo dot com
 Summary:unpack("a5", "str\0") does not work as expected
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux (3.0.0-15-generic)
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I don't see anything wrong here. 

unpack("a5", "foo\0\0")

removes the NULL padding from the input string. The 5 specifies only the size 
of the input to consume:

php > var_dump(unpack("a5", "foo\0"));
PHP Warning:  unpack(): Type a: not enough input, need 5, have 4 in php shell 
code on line 1


Previous Comments:

[2012-02-10 09:20:26] su dot hang at yahoo dot com

Description:

related bug: https://bugs.php.net/bug.php?id=39588

if unpacking from a binary string ending with any number of "\0"'s, and the 
unpack string length is given, the resulted string does not have the right 
length. 

for example, unpack("a5", "str\0") should result in a 5-byte-long string, but 
it returns a 3-byte-long instead. 

Test script:
---

  string(5) "str\0\0"
}

Actual result:
--
array(1) {
  [1]=>
  string(3) "str"
}






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


Bug #61038 [Nab]: unpack("a5", "str\0\0") does not work as expected

2012-02-10 Thread su dot hang at yahoo dot com
Edit report at https://bugs.php.net/bug.php?id=61038&edit=1

 ID: 61038
 User updated by:su dot hang at yahoo dot com
 Reported by:su dot hang at yahoo dot com
-Summary:unpack("a5", "str\0") does not work as expected
+Summary:unpack("a5", "str\0\0") does not work as expected
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux (3.0.0-15-generic)
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

sorry, please use the test script instead of the subject.

It is a bug because it is against the spec that "a" is an arbitrary binary 
string. 
If specified length is 5 then it should be null-padded at the end, rather than 
being 
truncated.

try unpack('a5', "\x12\x34\x00\x56\x00").
at least, to be consistent, the result string should terminate at the first 
"\0", 
instead of the trailing one.

btw, perl is handling it correctly.


Previous Comments:

[2012-02-10 16:34:10] cataphr...@php.net

I don't see anything wrong here. 

unpack("a5", "foo\0\0")

removes the NULL padding from the input string. The 5 specifies only the size 
of the input to consume:

php > var_dump(unpack("a5", "foo\0"));
PHP Warning:  unpack(): Type a: not enough input, need 5, have 4 in php shell 
code on line 1


[2012-02-10 09:20:26] su dot hang at yahoo dot com

Description:

related bug: https://bugs.php.net/bug.php?id=39588

if unpacking from a binary string ending with any number of "\0"'s, and the 
unpack string length is given, the resulted string does not have the right 
length. 

for example, unpack("a5", "str\0") should result in a 5-byte-long string, but 
it returns a 3-byte-long instead. 

Test script:
---

  string(5) "str\0\0"
}

Actual result:
--
array(1) {
  [1]=>
  string(3) "str"
}






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


Req #61004 [Wfx]: Add mysql_safe_query

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

 ID: 61004
 Updated by: ras...@php.net
 Reported by:pazzo at bahnhof dot se
 Summary:Add mysql_safe_query
 Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

No, what you are describing is prepared statements which are fully supported in 
both MySQLi and PDO. So the new interfaces do exactly what you propose.

See:

http://www.php.net/manual/en/mysqli.prepare.php
http://www.php.net/manual/en/pdo.prepare.php

Both the ? placeholder style you proposed and the even safer named placeholder 
style are supported:

eg.

$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit WHERE calories < ? AND colour = ?');
$sth->execute(array(150, 'red'));

and

$sql = 'SELECT name, colour, calories
FROM fruit WHERE calories < :calories AND colour = :colour';
$sth = $dbh->prepare($sql);
$sth->execute(array(':calories' => 150, ':colour' => 'red'));


Previous Comments:

[2012-02-10 08:42:05] pazzo at bahnhof dot se

Are you seriously telling me that PHP created a new MySQL interface without 
dealing with the bad design of the queries?


[2012-02-09 00:29:35] ahar...@php.net

ext/mysql is deprecated in PHP 5.4 (albeit without actual PHP warnings until 
PHP 
5.5). Migrating to mysqli or PDO is strongly recommended at this time, and the 
legacy MySQL extension won't be receiving new features.


[2012-02-08 21:59:43] phpmpan at mpan dot pl

Since people rarely refresh their knowledge, even when they know it's old, 
those links may help realizing that for at least few years there are newer and 
more secure solutions than old mysql extension:
- http://www.php.net/manual/en/book.pdo.php
- http://www.php.net/manual/en/book.mysqli.php


[2012-02-07 15:03:13] pazzo at bahnhof dot se

Description:

Since people are bad at securing their code, even when they know how, this 
function may give securer and more readable code:

mysql_safe_query('UPDATE people SET (name, number) VALUES ? WHERE name = ? or 
?` 
= ?',
 array('new name', 5553475), 'old name', 'custom field', 5);


I've provided an example of how to solve this using php code.

Test script:
---
http://pastebin.com/8EcS9y1B







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


Req #61004 [Wfx]: Add mysql_safe_query

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

 ID: 61004
 Updated by: ras...@php.net
 Reported by:pazzo at bahnhof dot se
 Summary:Add mysql_safe_query
 Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Note that this has been available in PHP since 2005, so it isn't exactly new.


Previous Comments:

[2012-02-10 16:58:11] ras...@php.net

No, what you are describing is prepared statements which are fully supported in 
both MySQLi and PDO. So the new interfaces do exactly what you propose.

See:

http://www.php.net/manual/en/mysqli.prepare.php
http://www.php.net/manual/en/pdo.prepare.php

Both the ? placeholder style you proposed and the even safer named placeholder 
style are supported:

eg.

$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit WHERE calories < ? AND colour = ?');
$sth->execute(array(150, 'red'));

and

$sql = 'SELECT name, colour, calories
FROM fruit WHERE calories < :calories AND colour = :colour';
$sth = $dbh->prepare($sql);
$sth->execute(array(':calories' => 150, ':colour' => 'red'));


[2012-02-10 08:42:05] pazzo at bahnhof dot se

Are you seriously telling me that PHP created a new MySQL interface without 
dealing with the bad design of the queries?


[2012-02-09 00:29:35] ahar...@php.net

ext/mysql is deprecated in PHP 5.4 (albeit without actual PHP warnings until 
PHP 
5.5). Migrating to mysqli or PDO is strongly recommended at this time, and the 
legacy MySQL extension won't be receiving new features.


[2012-02-08 21:59:43] phpmpan at mpan dot pl

Since people rarely refresh their knowledge, even when they know it's old, 
those links may help realizing that for at least few years there are newer and 
more secure solutions than old mysql extension:
- http://www.php.net/manual/en/book.pdo.php
- http://www.php.net/manual/en/book.mysqli.php


[2012-02-07 15:03:13] pazzo at bahnhof dot se

Description:

Since people are bad at securing their code, even when they know how, this 
function may give securer and more readable code:

mysql_safe_query('UPDATE people SET (name, number) VALUES ? WHERE name = ? or 
?` 
= ?',
 array('new name', 5553475), 'old name', 'custom field', 5);


I've provided an example of how to solve this using php code.

Test script:
---
http://pastebin.com/8EcS9y1B







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


[PHP-BUG] Bug #61046 [NEW]: Segfault when memory limit is hit while copying hash table

2012-02-10 Thread ni...@php.net
From: nikic
Operating system: 
PHP version:  5.4.0RC7
Package:  Reproducible crash
Bug Type: Bug
Bug description:Segfault when memory limit is hit while copying hash table

Description:

The attached test script triggers a segfault. It happens during the
shutdown after the memory limit is reached in the byRef($array) line.

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



[PHP-BUG] Bug #61047 [NEW]: easyapache not compiling

2012-02-10 Thread pandit dot dhruv at gmail dot com
From: 
Operating system: cent OS 6.2
PHP version:  5.3.10
Package:  Apache related
Bug Type: Bug
Bug description:easyapache not compiling

Description:

Installing PHP SAPI module:   apache2handler
/usr/local/apache/build/instdso.sh
SH_LIBTOOL='/usr/local/apache/build/libtool' libphp5.la
/usr/local/apache/modules
/usr/local/apache/build/libtool --mode=install cp libphp5.la
/usr/local/apache/modules/
cp .libs/libphp5.lai /usr/local/apache/modules/libphp5.la
cp .libs/libphp5.a /usr/local/apache/modules/libphp5.a
chmod 644 /usr/local/apache/modules/libphp5.a
ranlib /usr/local/apache/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish
/home/cpeasyapache/src/php-5.3.10/libs'
Warning!  dlname not found in /usr/local/apache/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/apache/modules/libphp5.so
chmod: cannot access `/usr/local/apache/modules/libphp5.so': No such file
or directory
apxs:Error: Command failed with rc=65536
.
make: *** [install-sapi] Error 1
!! 'make install' failed with exit code '512' !!
!! Restoring original working apache !!


Expected result:

i am trying to run easyapache , but getting this error.

and /usr/local/apache/modules/libphp5.so is already  there.


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



Bug #61046 [Com]: Segfault when memory limit is hit while copying hash table

2012-02-10 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=61046&edit=1

 ID: 61046
 Comment by: ni...@php.net
 Reported by:ni...@php.net
 Summary:Segfault when memory limit is hit while copying hash
 table
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

GDB Stacktrace:

#0  zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1  0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2  0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3  0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4  0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5  0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, 
apply_func=0x83c7310 , tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6  0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7  0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8  0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9  0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356


Previous Comments:

[2012-02-10 17:28:02] ni...@php.net

Description:

The attached test script triggers a segfault. It happens during the shutdown 
after the memory limit is reached in the byRef($array) line.

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


Bug #61046 [Opn]: Segfault when memory limit is hit while copying hash table

2012-02-10 Thread jpauli
Edit report at https://bugs.php.net/bug.php?id=61046&edit=1

 ID: 61046
 Updated by: jpa...@php.net
 Reported by:ni...@php.net
 Summary:Segfault when memory limit is hit while copying hash
 table
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

What I can say :

- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes 
the 
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k


Previous Comments:

[2012-02-10 17:31:28] ni...@php.net

GDB Stacktrace:

#0  zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1  0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2  0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3  0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4  0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5  0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, 
apply_func=0x83c7310 , tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6  0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7  0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8  0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9  0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356


[2012-02-10 17:28:02] ni...@php.net

Description:

The attached test script triggers a segfault. It happens during the shutdown 
after the memory limit is reached in the byRef($array) line.

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


Bug #61046 [Opn]: Segfault when memory limit is hit while copying hash table

2012-02-10 Thread jpauli
Edit report at https://bugs.php.net/bug.php?id=61046&edit=1

 ID: 61046
 Updated by: jpa...@php.net
 Reported by:ni...@php.net
 Summary:Segfault when memory limit is hit while copying hash
 table
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

Notice that I only reproduce with memory_limit set to accurate 512k , not 500k 
as 
in bug text, nor even 511k


Previous Comments:

[2012-02-10 17:34:21] jpa...@php.net

What I can say :

- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes 
the 
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k


[2012-02-10 17:31:28] ni...@php.net

GDB Stacktrace:

#0  zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1  0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2  0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3  0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4  0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5  0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, 
apply_func=0x83c7310 , tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6  0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7  0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8  0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9  0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356


[2012-02-10 17:28:02] ni...@php.net

Description:

The attached test script triggers a segfault. It happens during the shutdown 
after the memory limit is reached in the byRef($array) line.

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


Bug #61044 [Com]: invalid PHP_BINDIR

2012-02-10 Thread anon at anon dot anon
Edit report at https://bugs.php.net/bug.php?id=61044&edit=1

 ID: 61044
 Comment by: anon at anon dot anon
 Reported by:bugzilla33 at gmail dot com
 Summary:invalid PHP_BINDIR
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   win 7
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

He's right. This seems to be totally broken on Windows:

C:\>server\php\php.exe --version
PHP 5.3.2 (cli) (built: Mar  3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

C:\>server\php\php.exe -r "echo PHP_BINDIR";
C:\php5


Previous Comments:

[2012-02-10 13:42:02] bugzilla33 at gmail dot com

Description:

Install php in folder c:\Php5
As module apache

Test script:
---


Expected result:

c:\Php5

Actual result:
--
c:\Php






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


Bug #61046 [Opn]: Segfault when memory limit is hit while copying hash table

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

 ID: 61046
 Updated by: ras...@php.net
 Reported by:ni...@php.net
 Summary:Segfault when memory limit is hit while copying hash
 table
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

Same here. Reproducable on 64-bit Linux with memory_limit set to "512k".

The segfault is here:

zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at 
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);

(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8, 
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}

Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference 
*parent


Previous Comments:

[2012-02-10 17:46:09] jpa...@php.net

Notice that I only reproduce with memory_limit set to accurate 512k , not 500k 
as 
in bug text, nor even 511k


[2012-02-10 17:34:21] jpa...@php.net

What I can say :

- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes 
the 
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k


[2012-02-10 17:31:28] ni...@php.net

GDB Stacktrace:

#0  zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1  0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2  0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3  0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4  0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5  0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70, 
apply_func=0x83c7310 , tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6  0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7  0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8  0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9  0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356


[2012-02-10 17:28:02] ni...@php.net

Description:

The attached test script triggers a segfault. It happens during the shutdown 
after the memory limit is reached in the byRef($array) line.

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


[PHP-BUG] Bug #61049 [NEW]: Fopen detects non existing file

2012-02-10 Thread kasper at webmasteren dot eu
From: 
Operating system: windows
PHP version:  5.3SVN-2012-02-10 (snap)
Package:  Filesystem function related
Bug Type: Bug
Bug description:Fopen detects non existing file

Description:

Tested under PHP version 5.3.8 and 5.3.9, both running xdebug and a lot of
other 
standard plugins.
The problem is for some reason that PHP simply cannot create / open a file
named 
"../api/cache/con.js" which seems rather strange,since there is no keywords

(from what i could find) there would even suggest that it could be the
reason. 
i have used the software packet called "wamp". 

Configuration line:
cscript /nologo configure.js "--enable-snapshot-build"
"--with-pdo-oci=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared"
"--with-oci8=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8-
11g=C:\php-sdk\php53dev\vc9\x64\deps\instantclient_11_2\sdk,shared"
"--disable-
debug-pack" "--disable-static-analyze"

the version API:
API20090626,TS,VC9


The test script:
inside af subfolder, on a webserver, put this, and make sure that
../api/cache 
folder exists.

futher more, when using the SplFileInfo the method "getType" tells me that
it is 
a file. the method "getAbsolutePath" returns "c:\wamp\www\api\cache\CON"
and the 
"getFileName" returns "CON.js". 

Test script:
---
fopen("../api/cache/con.js","w");


Expected result:

Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open
stream: Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3



Actual result:
--
Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open
stream: Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3


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



Bug #61049 [Opn]: Fopen detects non existing file

2012-02-10 Thread kasper at webmasteren dot eu
Edit report at https://bugs.php.net/bug.php?id=61049&edit=1

 ID: 61049
 User updated by:kasper at webmasteren dot eu
 Reported by:kasper at webmasteren dot eu
 Summary:Fopen detects non existing file
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   windows
-PHP Version:5.3SVN-2012-02-10 (snap)
+PHP Version:5.3.8, 5.3.9
 Block user comment: N
 Private report: N

 New Comment:

realized the version was wrong (the date)


Previous Comments:

[2012-02-10 19:27:37] kasper at webmasteren dot eu

Description:

Tested under PHP version 5.3.8 and 5.3.9, both running xdebug and a lot of 
other 
standard plugins.
The problem is for some reason that PHP simply cannot create / open a file 
named 
"../api/cache/con.js" which seems rather strange,since there is no keywords 
(from what i could find) there would even suggest that it could be the reason. 
i have used the software packet called "wamp". 

Configuration line:
cscript /nologo configure.js "--enable-snapshot-build" "--with-pdo-oci=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8-
11g=C:\php-sdk\php53dev\vc9\x64\deps\instantclient_11_2\sdk,shared" "--disable-
debug-pack" "--disable-static-analyze"

the version API:
API20090626,TS,VC9


The test script:
inside af subfolder, on a webserver, put this, and make sure that ../api/cache 
folder exists.

futher more, when using the SplFileInfo the method "getType" tells me that it 
is 
a file. the method "getAbsolutePath" returns "c:\wamp\www\api\cache\CON" and 
the 
"getFileName" returns "CON.js". 

Test script:
---
fopen("../api/cache/con.js","w");


Expected result:

Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3



Actual result:
--
Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3







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


Bug #61049 [Opn->Nab]: Fopen detects non existing file

2012-02-10 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=61049&edit=1

 ID: 61049
 Updated by: cataphr...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Fopen detects non existing file
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Filesystem function related
 Operating System:   windows
 PHP Version:5.3.8, 5.3.9
 Block user comment: N
 Private report: N

 New Comment:

This is a Win32 quirk. The interface PHP uses has problems with files named 
CON, 
among others:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

«Do not use the following reserved device names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, 
LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names 
followed immediately by an extension; for example, NUL.txt is not recommended. 
For more information, see Namespaces.»


Previous Comments:

[2012-02-10 19:28:55] kasper at webmasteren dot eu

realized the version was wrong (the date)


[2012-02-10 19:27:37] kasper at webmasteren dot eu

Description:

Tested under PHP version 5.3.8 and 5.3.9, both running xdebug and a lot of 
other 
standard plugins.
The problem is for some reason that PHP simply cannot create / open a file 
named 
"../api/cache/con.js" which seems rather strange,since there is no keywords 
(from what i could find) there would even suggest that it could be the reason. 
i have used the software packet called "wamp". 

Configuration line:
cscript /nologo configure.js "--enable-snapshot-build" "--with-pdo-oci=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8-
11g=C:\php-sdk\php53dev\vc9\x64\deps\instantclient_11_2\sdk,shared" "--disable-
debug-pack" "--disable-static-analyze"

the version API:
API20090626,TS,VC9


The test script:
inside af subfolder, on a webserver, put this, and make sure that ../api/cache 
folder exists.

futher more, when using the SplFileInfo the method "getType" tells me that it 
is 
a file. the method "getAbsolutePath" returns "c:\wamp\www\api\cache\CON" and 
the 
"getFileName" returns "CON.js". 

Test script:
---
fopen("../api/cache/con.js","w");


Expected result:

Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3



Actual result:
--
Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3







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


Bug #61049 [Com]: Fopen detects non existing file

2012-02-10 Thread anon at anon dot anon
Edit report at https://bugs.php.net/bug.php?id=61049&edit=1

 ID: 61049
 Comment by: anon at anon dot anon
 Reported by:kasper at webmasteren dot eu
 Summary:Fopen detects non existing file
 Status: Not a bug
 Type:   Bug
 Package:Filesystem function related
 Operating System:   windows
 PHP Version:5.3.8, 5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Sadly this is a Windows limitation. On Windows you cannot create a file named 
"con", "aux", "prn", or "nul", regardless of case. They are reserved device 
names that exist for historical reasons ("con" for example is the 
stdin/stdout). For some mad reason, this limitation still applies regardless of 
the file extension!! Try simply in Notepad to save a file called con.txt and 
it'll fail just the same.


Previous Comments:

[2012-02-10 20:32:57] cataphr...@php.net

This is a Win32 quirk. The interface PHP uses has problems with files named 
CON, 
among others:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

«Do not use the following reserved device names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, 
LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names 
followed immediately by an extension; for example, NUL.txt is not recommended. 
For more information, see Namespaces.»


[2012-02-10 19:28:55] kasper at webmasteren dot eu

realized the version was wrong (the date)


[2012-02-10 19:27:37] kasper at webmasteren dot eu

Description:

Tested under PHP version 5.3.8 and 5.3.9, both running xdebug and a lot of 
other 
standard plugins.
The problem is for some reason that PHP simply cannot create / open a file 
named 
"../api/cache/con.js" which seems rather strange,since there is no keywords 
(from what i could find) there would even suggest that it could be the reason. 
i have used the software packet called "wamp". 

Configuration line:
cscript /nologo configure.js "--enable-snapshot-build" "--with-pdo-oci=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8=C:\php-
sdk\php53dev\vc9\x64\deps\instantclient_10_2\sdk,shared" "--with-oci8-
11g=C:\php-sdk\php53dev\vc9\x64\deps\instantclient_11_2\sdk,shared" "--disable-
debug-pack" "--disable-static-analyze"

the version API:
API20090626,TS,VC9


The test script:
inside af subfolder, on a webserver, put this, and make sure that ../api/cache 
folder exists.

futher more, when using the SplFileInfo the method "getType" tells me that it 
is 
a file. the method "getAbsolutePath" returns "c:\wamp\www\api\cache\CON" and 
the 
"getFileName" returns "CON.js". 

Test script:
---
fopen("../api/cache/con.js","w");


Expected result:

Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3



Actual result:
--
Warning: fopen(../api/cache/con.js) [function.fopen]: failed to open stream: 
Bad 
file descriptor in C:\wamp\www\teater\indexa.php on line 3







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


[PHP-BUG] Bug #61051 [NEW]: Unable to compile pdo-mysql

2012-02-10 Thread php at martins-creations dot co dot uk
From: 
Operating system: Debian
PHP version:  5.4.0RC7
Package:  Compile Failure
Bug Type: Bug
Bug description:Unable to compile pdo-mysql

Description:

Compilation error. I get this if I omit --with-pdo-mysql too, I think
--with-pdo-
sqlite is default. In such case I get a different error: 

...
Zend/zend_default_classes.lo Zend/zend_execute.lo
main/internal_functions_cli.lo 
sapi/cli/php_cli.lo sapi/cli/php_http_parser.lo sapi/cli/php_cli_server.lo
-
lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lrt -lxml2 -lxml2 -lxml2
-
lcrypt -lxml2 -lxml2 -lxml2 -lcrypt  -o sapi/cli/php
ext/pdo_sqlite/.libs/pdo_sqlite.o: In function `get_module':
/usr/local/src/php-5.4.0RC7/ext/pdo_sqlite/pdo_sqlite.c:74: multiple
definition 
of `get_module'
ext/pdo/.libs/pdo.o:/usr/local/src/php-5.4.0RC7/ext/pdo/pdo.c:171: first
defined 
here
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Test script:
---
$ ./configure --enable-fpm --enable-cli --enable-mbstring
--enable-inline-optimization --with-pdo-mysql
$ make && make install

Expected result:

Generating files
configure: creating ./config.status
,,

Actual result:
--
.
Zend/zend_default_classes.lo Zend/zend_execute.lo
main/internal_functions_cli.lo 
sapi/cli/php_cli.lo sapi/cli/php_http_parser.lo sapi/cli/php_cli_server.lo
-
lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lrt -lxml2 -lxml2 -lxml2
-
lcrypt -lxml2 -lxml2 -lxml2 -lcrypt  -o sapi/cli/php
ext/pdo_sqlite/.libs/pdo_sqlite.o: In function `get_module':
/usr/local/src/php-5.4.0RC7/ext/pdo_sqlite/pdo_sqlite.c:74: multiple
definition 
of `get_module'
ext/pdo/.libs/pdo.o:/usr/local/src/php-5.4.0RC7/ext/pdo/pdo.c:171: first
defined 
here
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1


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



Bug #61051 [Opn->Csd]: Unable to compile pdo-mysql

2012-02-10 Thread php at martins-creations dot co dot uk
Edit report at https://bugs.php.net/bug.php?id=61051&edit=1

 ID: 61051
 User updated by:php at martins-creations dot co dot uk
 Reported by:php at martins-creations dot co dot uk
 Summary:Unable to compile pdo-mysql
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Debian
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

make clean :<


Previous Comments:

[2012-02-10 21:04:11] php at martins-creations dot co dot uk

Description:

Compilation error. I get this if I omit --with-pdo-mysql too, I think 
--with-pdo-
sqlite is default. In such case I get a different error: 

...
Zend/zend_default_classes.lo Zend/zend_execute.lo 
main/internal_functions_cli.lo 
sapi/cli/php_cli.lo sapi/cli/php_http_parser.lo sapi/cli/php_cli_server.lo -
lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lrt -lxml2 -lxml2 -lxml2 -
lcrypt -lxml2 -lxml2 -lxml2 -lcrypt  -o sapi/cli/php
ext/pdo_sqlite/.libs/pdo_sqlite.o: In function `get_module':
/usr/local/src/php-5.4.0RC7/ext/pdo_sqlite/pdo_sqlite.c:74: multiple definition 
of `get_module'
ext/pdo/.libs/pdo.o:/usr/local/src/php-5.4.0RC7/ext/pdo/pdo.c:171: first 
defined 
here
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Test script:
---
$ ./configure --enable-fpm --enable-cli --enable-mbstring 
--enable-inline-optimization --with-pdo-mysql
$ make && make install

Expected result:

Generating files
configure: creating ./config.status
,,

Actual result:
--
.
Zend/zend_default_classes.lo Zend/zend_execute.lo 
main/internal_functions_cli.lo 
sapi/cli/php_cli.lo sapi/cli/php_http_parser.lo sapi/cli/php_cli_server.lo -
lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lrt -lxml2 -lxml2 -lxml2 -
lcrypt -lxml2 -lxml2 -lxml2 -lcrypt  -o sapi/cli/php
ext/pdo_sqlite/.libs/pdo_sqlite.o: In function `get_module':
/usr/local/src/php-5.4.0RC7/ext/pdo_sqlite/pdo_sqlite.c:74: multiple definition 
of `get_module'
ext/pdo/.libs/pdo.o:/usr/local/src/php-5.4.0RC7/ext/pdo/pdo.c:171: first 
defined 
here
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1







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


Bug #61044 [Opn->Asn]: invalid PHP_BINDIR

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=61044&edit=1

 ID: 61044
 Updated by: johan...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:invalid PHP_BINDIR
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   win 7
 PHP Version:5.4.0RC7
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

This is defined while compiling PHP (prefix-option from compile.js), the way to 
fix this would be to do some run-time detection, not sure whether there's a 
proper way.


Previous Comments:

[2012-02-10 18:05:38] anon at anon dot anon

He's right. This seems to be totally broken on Windows:

C:\>server\php\php.exe --version
PHP 5.3.2 (cli) (built: Mar  3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans

C:\>server\php\php.exe -r "echo PHP_BINDIR";
C:\php5


[2012-02-10 13:42:02] bugzilla33 at gmail dot com

Description:

Install php in folder c:\Php5
As module apache

Test script:
---


Expected result:

c:\Php5

Actual result:
--
c:\Php






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


Bug #61025 [Opn]: __invoke() visibility not honored

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=61025&edit=1

 ID: 61025
 Updated by: johan...@php.net
 Reported by:jpa...@php.net
 Summary:__invoke() visibility not honored
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   *nix
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Yes, the current behavior is wrong. I don't think it should be fixed in 5.3 
though as the fix might break existing code.


Previous Comments:

[2012-02-09 09:17:23] jpa...@php.net

Description:

__invoke() visibility is not honored when indirectly called as $obj().
It is, when directly called, via $obj->__invoke();

Please, note as well that declaring __invoke() as static works as well, I think 
it shouldn't (nonsense)

Test script:
---
__invoke(); */

Expected result:

Call to private method Bar::__invoke() from context ...

Actual result:
--
Bar






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


Bug #60879 [Asn]: unserialize() Does not invoke __wakeup() on object

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60879&edit=1

 ID: 60879
 Updated by: johan...@php.net
 Reported by:thijsputman at gmail dot com
 Summary:unserialize() Does not invoke __wakeup() on object
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Windows 7
 PHP Version:5.4.0RC6
-Assigned To:johannes
+Assigned To:szarkos
 Block user comment: N
 Private report: N

 New Comment:

Steve,

I can't verify the report on Linux and don't see a related code-change. As I 
don't have a proper Windows environment at hand: From the report the user gave 
it seems like the compiler would do some over-optimistic optimization, can you 
take a look into this?

Also please mind the notes on the other small issues in the configure lines.


Previous Comments:

[2012-02-08 14:02:24] thijsputman at gmail dot com

The configure commands between RC7-dev (which works properly) and RC7 (which 
exhibits the problem) seem to differ a bit, could that be the cause?

RC7 contains the following elements not contained in RC7-dev:
--disable-nsapi --with-enchant=shared --disable-static-analyze --with-pgo

RC7-dev contains the following not contained in RC7:
--enable-object-out-dir=d:/temp/obj/nts-windows-vc9-x86

Also, there seems to be a small typo in the RC7-dev configure command:
"--enable-snapshot-build --disable-zts --disable-isapi --enable-debug-pack 
--disable-isapi" 

ISAPI is disabled twice (I'm guessing the second one should be nsapi?)


[2012-02-08 13:46:27] thijsputman at gmail dot com

Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the 
problem has reappeared...


[2012-02-06 13:44:29] yoozer at gmail dot com

I've just tested the official release of RC7; it still exhibits this issue with 
exactly the same testcase.


[2012-01-26 11:33:25] johan...@php.net

So let's assume this was fixed. I can't see a relevant change for this, though. 
There will be another RC soon, an you check that, too, to be safe? Thanks :-)


[2012-01-26 10:56:17] thijsputman at gmail dot com

Just tried with revision 322785 and it indeed works as expected.

To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe, 
2012-Jan-19 23:40:07) from the QA website and in that release the problem does 
exist.




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


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


Req #5975 [Opn->Dup]: version of strip_tags() that specifies tags to strip (instead of tags to keep)

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=5975&edit=1

 ID: 5975
 Updated by: johan...@php.net
 Reported by:muhlig at us dot edu dot pl
 Summary:version of strip_tags() that specifies tags to strip
 (instead of tags to keep)
-Status: Open
+Status: Duplicate
 Type:   Feature/Change Request
 Package:Strings related
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

See bug #23723


Previous Comments:

[2011-02-26 20:40:33] jthijssen at noxlogic dot nl

This bug is a duplicate of #23723. A patch for this feature is added to that 
bug.


[2000-08-04 20:51:01] muhlig at us dot edu dot pl

Because I'd like to strip much less tags than I'd like to remain in the HTML 
file (and I suppose there are more people who would like such a feature) I'd 
suggest to accompany strip_tags with its counterpart:

string strip_tags (string str [, string allowable_tags])

in the following way (more or less):

string strip_some_tags (string str [, string not_allowable_tags])

or enhance strip_tags in order to allow only these tags which are not
allowed to exist in the resulting string.







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


Bug #60425 [Opn->Nab]: php 5.3.3 - Duild Date: Jul 21 2010 20:00:47

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60425&edit=1

 ID: 60425
 Updated by: johan...@php.net
 Reported by:ol_b at meta dot ua
 Summary:php 5.3.3 - Duild Date: Jul 21 2010 20:00:47
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Strings related
 Operating System:   Windows XP SP3
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

The function works, as all of "core" PHP on binary data. You can use 
mb_convert_case with MB_CASE_TITLE option for non-ASCII text.


Previous Comments:

[2011-12-01 15:23:35] ol_b at meta dot ua

Header shows file charset.


[2011-12-01 14:19:04] ol_b at meta dot ua

Description:

ucwords() - Uppercase the first character of each word in a string - doesn't 
work with UTF-8 Cyrillic text.

http://cs10006.vk.com/u17937332/128685919/y_64c60ec2.jpg

Test script:
---


";
echo ucwords('тест тест тест');  //Тест Тест Тест
?>







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


Bug #60428 [Opn->Wfx]: $this as byref

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60428&edit=1

 ID: 60428
 Updated by: johan...@php.net
 Reported by:bjorn at hcbmedia dot nl
 Summary:$this as byref
-Status: Open
+Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Any
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

This is caused by different optimisations for access to $this we have. The only 
way we could detect this is by preventing to pass $this by reference, which 
isn't a good restriction in the language. Afterwards, in your ref method we 
have no way to figure out that $this was passed. Therefore we all have to live 
with this.


Previous Comments:

[2011-12-01 15:01:29] bjorn at hcbmedia dot nl

Description:

take a look at the following script

ref ($this); // exchange $this by a B object
var_dump ($this); // B
var_dump ($this->a); // 6
var_dump ($this->b); // Notice: Undefined property: A::$b
var_dump (isset ($this->a)); // true
var_dump (property_exists ($this, "a")); // false
var_dump (__CLASS__); // A
$this->whoami (); // A
var_dump ($this instanceof self ? "A" : "B"); // B
}

function ref (A &$ref) {
$ref = new B();
}

public function whoami () {
var_dump (__CLASS__);
}
}

$a = new A();
$a->thisref ();
?>

it supplies $this variable as a property to a byref function, then changing it 
to a diffrent type.

if gives some strange results

Expected result:

it should not be possible to supply $this as a byref param

Actual result:
--
$this seems to be changed, however any call upon $this seems not, so properties 
and methods remain unchanged.






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


[PHP-BUG] Bug #61052 [NEW]: missing error check in trait 'insteadof' clause

2012-02-10 Thread ottoni at fb dot com
From: 
Operating system: Linux
PHP version:  5.4.0RC7
Package:  *Compile Issues
Bug Type: Bug
Bug description:missing error check in trait 'insteadof' clause

Description:

See example script.

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



Bug #60695 [Opn->Nab]: bind_param 'd' appends a 0

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60695&edit=1

 ID: 60695
 Updated by: johan...@php.net
 Reported by:nbari at dalmp dot com
 Summary:bind_param  'd' appends a 0
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:MySQLi related
 Operating System:   FreeBSD
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

this depends on the conversion the MySQL server does. If you want some string 
value send it as string ... else -> MySQL Server Issue, not PHP


Previous Comments:

[2012-02-05 07:27:05] nbari at dalmp dot com

the problem seems to only occur with MySQL version 5.1, testing with MySQL 
version >= 5.5 the results are as expected


[2012-01-10 23:44:19] nbari at dalmp dot com

The point is that when using 'd' a 0 shouldn't be appended to the inputed value.

Using 's' works but the 'posible' bug report is related that to the 'd' 

When using 'i' the stored value is like the expected, example 99.3 will store 
only 99 and remove the .3 .

But when using 'd' the stored value instead of been or continue to be like the 
input, in some cases an 0 is appended. 

example: 

99.3 is stored like 99.30
99.31 is stored like 99.31
1.1 is stored like 1.10
1.31 is stored like 1.31

for an unknown reason only doubles with 1 decimal are stored or reformatted to 
be 
have 2 decimals


[2012-01-10 23:13:35] anon at anon dot anon

>The type of column 'name' is text()
Then bind it as 's'.


[2012-01-10 12:08:47] nbari at dalmp dot com

The type of column 'name' is text()

After inserting the data, I query via mysql console directly on a terminal and 
notice the 0, so i can confirm it is not an issue with a software displaying or 
formatting numbers with 2 decimal places. 

I made the same test using 'i' (for integer) and instead of 99.3 the stored 
value 
was just 99 (no 0 appended), when using 's' is is working but I start noticing 
this strange behaivor when the search string was an double.

my search query/code is like this: 

$sql = 'select id from test where name=?';

$param = $_POST['name'];
if (is_numeric($param)) {
   $param = !strcmp(intval($param), $param) ? (int)$param : 
(!strcmp(floatval($param), $param) ? (float)$param : $param);
 }
 $type = is_int($param) ? 'i' : (is_float($param) ? 'd' : (is_string($param) ? 
's' : 'b'));

$stmt->bind_param($type,$param);
$stmt->execute();
$stmt->close();


Initially I though that the 'sanitation' made was affecting the results  but 
later manually I specified the types and notice that only with doubles 'd' this 
was happening.


[2012-01-10 05:44:34] anon at anon dot anon

What is the type of the column 'name'?

If it's a string, then bind it as 's' instead of 'd'. If it's a double, there's 
no problem; it's the same number and the internal bits of a double do not have 
a way to represent "93.3" and "93.30" differently -- the bits are identical, so 
the issue is the program or code you're using for *displaying* the number is 
formatting it with 2 decimal places on purpose.




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


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


Bug #60601 [Opn->Nab]: ReflectionMethod::InvokeArgs not work normally in function

2012-02-10 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60601&edit=1

 ID: 60601
 Updated by: johan...@php.net
 Reported by:joelp at email dot cz
 Summary:ReflectionMethod::InvokeArgs not work normally in
 function
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

as the error message says mysqli_stmt::bind_param() expects references. When 
called in this indirect way there is nothing which can be used as a reference.


Previous Comments:

[2012-01-05 08:58:23] joelp at email dot cz

Yes this works. But that not solved, why this code work correctly outside of 
the function and not works inside.


[2011-12-29 01:11:31] hanskrentel at yahoo dot de

This is not a bug but a problem how you pass the arguments.

As the warning says, you need to give a variable, but you give values:

$variables = array ("one62","two62");

Instead give variables:

$var1 = "one62";
$var2 = "two62";
$variables = array (&$var1, &$var2);

Hope this is helpful.


[2011-12-23 13:56:49] joelp at email dot cz

Description:

If I try to use ReflectionMethod::InvokeArgs after using function array_unshift 
inside of user function, this return me this:

Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference, 
value given in /www/transaction_test.php on line 132

Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation 
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132 
Stack trace: #0 /www/transaction_test.php(132): 
ReflectionMethod->invokeArgs(Object(mysqli_stmt), Array) #1 
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array, 
'ss') #2 {main} thrown in /www/transaction_test.php on line 132


If I try run it out of user function. Everything is OK. 


Test script:
---
function test_case_function ($sql,$variables,$vars) {
  $mysqli = new mysqli(db_server, db_user_name, db_user_passwd, db_name);
  $mysqli->query("SET NAMES 'utf8'") or die ('Could not set Charset');
  $mysqli->autocommit(FALSE);



array_unshift($variables,$vars);




  if ($stm=$mysqli->prepare($sql)) {
$method= new ReflectionMethod('mysqli_stmt','bind_param');
$method->invokeArgs($stm,$variables);
}

  $stm->execute();
  printf("%d Row inserted\n", $stm->affected_rows);
  $mysqli->commit();
  $stm->close();
  $mysqli->close();
}

$sql = "INSERT INTO `test_table` (`time`,`one`,`two`) VALUES (NOW(),?,?);";
$vars = 'ss';
$variables = array ("one62","two62");

test_case_function($sql,$variables,$vars);

Expected result:

Script print "1 Row inserted "

Actual result:
--
Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference, 
value given in /www/transaction_test.php on line 132

Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation 
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132 
Stack trace: #0 /www/transaction_test.php(132): 
ReflectionMethod->invokeArgs(Object(mysqli_stmt), Array) #1 
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array, 
'ss') #2 {main} thrown in /www/transaction_test.php on line 132






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


Bug #60701 [Com]: __toString() which stores $this reference triggers segfault (with fix!)

2012-02-10 Thread andrew at localcoast dot net
Edit report at https://bugs.php.net/bug.php?id=60701&edit=1

 ID: 60701
 Comment by: andrew at localcoast dot net
 Reported by:daan at react dot com
 Summary:__toString() which stores $this reference triggers
 segfault (with fix!)
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   CentOS
 PHP Version:5.3.8
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

I can produce a similar issue on PHP 5.3.10 on Ubuntu 10.04 LTS x86_64 with the 
patch applied. However, the initial test script provided in the first comment 
runs without trouble.


Here's the backtrace for the issue I am having:

http://paste2.org/p/1900387
#0  0x7f71fa9b8d11 in gc_zval_possible_root (zv=0x7f7201483740) at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_gc.c:143
#1  0x7f71fa9a777b in zend_hash_destroy (ht=0x7f7201496908) at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_hash.c:529
p = 0x7f7201497c58
#2  0x7f71fa9ba379 in zend_object_std_dtor (object=0x7f7201497428) at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:45
#3  0x7f71fa9ba399 in zend_objects_free_object_storage 
(object=0x7f7201483740) at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:126
#4  0x7f71fa9bdba8 in zend_objects_store_free_object_storage 
(objects=0x7f71fb162a18) at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects_API.c:92
i = 626
#5  0x7f71fa98ebfb in shutdown_executor () at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_execute_API.c:304
__bailout = {{__jmpbuf = {140127520564832, -3282099667358606386, 
140127614418320, 0, -4294967295, 140127589456664, -3211606770996110386, 
-3282099660654535730}, __mask_was_saved = 0, __saved_mask = {__val = 
{140127612053568, 96, 140127512287676, 
140127629890216, 140127638595144, 88, 140127512287676, 592, 
140127512287676, 140127520566336, 140127520563352, 140127520564648, 0, 
18446744069414584321, 140127512403989, 140127520566336
#6  0x7f71fa99b612 in zend_deactivate () at 
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend.c:891
#7  0x7f71fa947ad5 in php_request_shutdown (dummy=) at 
/home/andrew/.Applications/build/php-5.3.10-patched/main/main.c:1661
report_memleaks = 1 '\001'
#8  0x7f71faa24a97 in php_apache_request_dtor (r=) at 
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:509
#9  php_handler (r=) at 
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:681
ctx = 0x7f7200ae5840
conf = 0x7f7200689c98
brigade = 0x7f7200ae6658
bucket = 
rv = 
parent_req = 0x0
#10 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ae3d90) at 
/build/buildd/apache2-2.2.14/server/config.c:159
n = 6
rv = -2039876096
#11 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ae3d90) at 
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x7f7200ad61d8 "Xa\255"
result = 11362776
old_handler = 0x7f7200792ec8 "application/x-httpd-php"
ignore = 
#12 0x7f71ff0f45fc in ap_internal_redirect (new_uri=, 
r=) at 
/build/buildd/apache2-2.2.14/modules/http/http_request.c:501
new = 0x7f7200ae3d90
access_status = -2039876096
#13 0x7f71f664dc95 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
No symbol table info available.
#14 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ad61d8) at 
/build/buildd/apache2-2.2.14/server/config.c:159
n = 7
rv = -2039876096
#15 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ad61d8) at 
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x0
result = 0
old_handler = 0x7f71f6651e58 "redirect-handler"
ignore = 
#16 0x7f71ff0f47d8 in ap_process_request (r=0x7f7200ad61d8) at 
/build/buildd/apache2-2.2.14/modules/http/http_request.c:282
access_status = -2039876096
#17 0x7f71ff0f1688 in ap_process_http_connection (c=0x7f7200ad0118) at 
/build/buildd/apache2-2.2.14/modules/http/http_core.c:190
r = 0x7f7200ad61d8
csd = 0x0
#18 0x7f71ff0eae38 in ap_run_process_connection (c=0x7f7200ad0118) at 
/build/buildd/apache2-2.2.14/server/connection.c:43
n = 2
rv = -2039876096
#19 0x7f71ff0f97a7 in child_main (child_num_arg=) at 
/build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:662
current_conn = 
csd = 0x7f7200acff28
ptrans = 0x7f7200acfea8
allocator = 0x7f7200acdda0
status = 
i = 
lr = 
pollset = 0x7f7200acdfc8
sbh = 0x7f7200acdfc0
bucket_alloc = 0x7f7200ad4148
last_poll_idx = 0
#20 0x7f71ff0f9a76 in make_child (s=0x7f72005dc938, slot=0) at 
/buil

[PHP-BUG] Req #61053 [NEW]: mysql_fetch_field should return type = "enum" and enum options

2012-02-10 Thread zzatkin at gmail dot com
From: 
Operating system: Linux
PHP version:  5.3.10
Package:  MySQL related
Bug Type: Feature/Change Request
Bug description:mysql_fetch_field should return type = "enum" and enum options

Description:

mysql_fetch_field returns type = "string" for enum fields in the MySQL
database, 
but should instead return "enum" and an array of possible values for
convenience.

Test script:
---


Expected result:

array(12) {
...
["type"]=>
string(6) "string"
...
}

Actual result:
--
array(12) {
...
["type"]=>
array(3) {
string(1) "a"
[1]=>
string(1) "b"
[2]=>
string(1) "c"
}
...
}

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



Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property

2012-02-10 Thread larue...@php.net
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1

 ID: 61011
 Patch added by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328929988
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988


Previous Comments:

[2012-02-08 16:07:37] larue...@php.net

I am not sure whether the patch is okey(it seems related to CACHE mechanism). 
anyway the patch will show where the problem comes from. 

Dmitry, could plz look at this?  thanks .


[2012-02-08 16:05:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158


[2012-02-08 16:05:36] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135


[2012-02-08 14:47:27] ahar...@php.net

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static 
property 
on a non-existent class with an autoloader registered if the __autoload() 
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0, 
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 






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


Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property

2012-02-10 Thread larue...@php.net
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1

 ID: 61011
 Patch added by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328930087
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328930087


Previous Comments:

[2012-02-11 03:13:08] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328929988
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988


[2012-02-08 16:07:37] larue...@php.net

I am not sure whether the patch is okey(it seems related to CACHE mechanism). 
anyway the patch will show where the problem comes from. 

Dmitry, could plz look at this?  thanks .


[2012-02-08 16:05:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158


[2012-02-08 16:05:36] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135


[2012-02-08 14:47:27] ahar...@php.net

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static 
property 
on a non-existent class with an autoloader registered if the __autoload() 
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0, 
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 



Bug #61011 [Com]: Crash when an exception is thrown by __autoload accessing a static property

2012-02-10 Thread larue...@php.net
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1

 ID: 61011
 Comment by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Hi, I attached a improved patch and phpt.  thanks


Previous Comments:

[2012-02-11 03:14:47] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328930087
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328930087


[2012-02-11 03:13:08] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328929988
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988


[2012-02-08 16:07:37] larue...@php.net

I am not sure whether the patch is okey(it seems related to CACHE mechanism). 
anyway the patch will show where the problem comes from. 

Dmitry, could plz look at this?  thanks .


[2012-02-08 16:05:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158


[2012-02-08 16:05:36] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135




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


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