Req #45351 [Com]: Exception::getTrace() should return 'object' array-element

2012-08-16 Thread jachym dot tousek at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=45351&edit=1

 ID: 45351
 Comment by: jachym dot tousek at gmail dot com
 Reported by:lasse100 at planet dot nl
 Summary:Exception::getTrace() should return 'object'
 array-element
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.3
 Block user comment: N
 Private report: N

 New Comment:

Why is this feature not yet integrated in PHP?


Previous Comments:

[2008-06-24 20:23:26] lasse100 at planet dot nl

Description:

As in function debug_backtrace(), the method Exception::getTrace() should 
return a array with a 'object' element, representing the current object.

The method Exception::getTrace() should also have a $provide_object parameter 
like the parameter in function debug_backtrace(), to disable the 
'object'-element in the array.

Reproduce code:
---
bar = $bar;
echo 'debug_backtrace: ';
var_dump(debug_backtrace());
echo '';
throw new Exception('Foo throws an exception!');
}
}
try {
$foo = new Foo('test');
} catch (Exception $e) {
echo 'Exception::getTrace(): ';
var_dump($e->getTrace());
echo '';
}
?>

Expected result:

debug_backtrace:

array(1) {
  [0]=>
  array(7) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  &string(4) "test"
}
  }
}

Exception::getTrace():

array(1) {
  [0]=>
  array(6) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  string(4) "test"
}
  }
}

Actual result:
--
debug_backtrace:

array(1) {
  [0]=>
  array(7) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  &string(4) "test"
}
  }
}

Exception::getTrace():

array(1) {
  [0]=>
  array(6) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  string(4) "test"
}
  }
}






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


[PHP-BUG] Bug #62836 [NEW]: Seg fault or broken object references on unserialize()

2012-08-16 Thread daniel dot beardsley at gmail dot com
From: daniel dot beardsley at gmail dot com
Operating system: CentOS
PHP version:  5.4.5
Package:  Reproducible crash
Bug Type: Bug
Bug description:Seg fault or broken object references on unserialize()

Description:

Occurs on php 5.4.0, but not on 5.3 (I'll try on other versions soon).
Please run this test from /tmp/serialize/run_tests.sh (see bottom for 
explanation)

## Description ##

If calling unserialize() somehow calls back into user code (i.e.
autoloading a
class while unserializing it) and user code does another unserialize() (no

matter what it is), object references in the outer unserialization process
won't 
be restored correctly. Sometimes the outer call can result in a
Segmentation 
Fault instead of just broken references.

In particular, object refrerences will often be replaced with a seemingly
random
value from your serialized object graph (or NULL).

The call stack at the time of the problem looks like this:

  #0 /tmp/serialize/setup.php(6): unserialize('i:4');
  #1 [internal function]: __autoload('A')
  #2 /tmp/serialize/unserialize_autoload.php(4): unserialize('O:1:"A":4:
{s:1:...')
  #3 {main}

The unserialize call in frame #2 returns incorrect results because of the 
"recursive" unserialize call in frame #0.

Note:
For reasons that completely escape me, this code seems dependent on the
literal 
path it's run from.  Some paths hide the bug, some cause failure, and some
cause 
a SegFault.  It's consistent on a per-path basis, but I found no pattern.  

Test script:
---
https://gist.github.com/3353895

Expected result:

Before and After output should be the same. Last line of output should
read: 
"Passed, no differences"

Before Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0) {
  }
  public $b1 =>
  class B#2 (0) {
  }
  public $c =>
  class B#3 (0) {
  }
  public $c1 =>
  class B#3 (0) {
  }
}

Actual result:
--
After Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0) {
  }
  public $b1 =>
  string(2) "1\000"
  public $c =>
  class B#3 (0) {
  }
  public $c1 =>
  NULL
}


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



[PHP-BUG] Bug #62837 [NEW]: ISAPI方式使用PHP,会导致web服务器崩溃.

2012-08-16 Thread 175384354 at qq dot com
From: 175384354 at qq dot com
Operating system: windows server 2003
PHP version:  5.3.15
Package:  *General Issues
Bug Type: Bug
Bug description:ISAPI方式使用PHP,会导致web服务器崩溃.

Description:

php post

Test script:
---









$value){   //用foreach循环
处理多个文件的上传
//2.判断文件是否上传错误

if($up_info[$k_name]['error']>0){
switch($up_info['error'][$i]){
case 1:
$err_info="上传的文件超过了 php.ini 中
upload_max_filesize 选项限制的值";
break;
case 2:
$err_info="上传文件的大小超过了 HTML 表单中
MAX_FILE_SIZE 选项指定的值";
break;
case 3:
$err_info="文件只有部分被上传";
break;
case 4:
$err_info="没有文件被上传";
break;
case 6:
$err_info="找不到临时文件夹";
break;
case 7:
$err_info="文件写入失败";
break;
default:
$err_info="未知的上传错误";
break;
}
continue($err_info);
}
$exten_name=pathinfo($up_info[$k_name]['name'],PATHINFO_EXTENSION);

do{
$main_name=date('YmHis'.'--'.rand(100,999));
$new_name=$main_name.'.'.$exten_name;
}while(file_exists($to_path.'/'.$new_name));


//6.判断是否是上传的文件,并执行上传

if(is_uploaded_file($up_info[$k_name]['tmp_name'])){

   
if(move_uploaded_file($up_info[$k_name]['tmp_name'],$upload_dir.'/'.$new_name)){
echo '上传成功!';
}else{
echo '上传文件移动失败!';
}
}else{
echo '文件不是上传的文件';
}

}   //for循环的括号

while ($file = readdir($handle)) {
   if(!is_dir($file) && !is_link($file)) {
  $filelist .= "".$file."";
  if ($DELETABLE)
$filelist .= " x";
  $filelist .= " ".date("d-m H:i",
filemtime($upload_dir.$file))."";
  $filelist .="";
   }
}
echo "COOKIE:".$HTTP_COOKIE_VARS['myup']."";
echo  $filelist;

?>

Expected result:

PHP从PHP5.2.17到5.3.15
都存在一个问题,会导致WEB服务器程序崩溃。
BUG描述:
服务器操作系统:windows server 2003
浏览器:MS IE 7.0
PHP使用方式:isapi

打开一个POST上传文件的PHP页面并上传一个文件,如果让这个上传页面闲置十几分钟以上,再次提交上传,会导致WEB服务器崩溃,而且没有任何提示。




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



Bug #62837 [Opn]: ISAPI方式使用PHP,会导致web服务器崩溃.

2012-08-16 Thread 175384354 at qq dot com
Edit report at https://bugs.php.net/bug.php?id=62837&edit=1

 ID: 62837
 User updated by:175384354 at qq dot com
 Reported by:175384354 at qq dot com
 Summary:ISAPI方式使用PHP,会导致web服务器崩溃.
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   windows server 2003
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

其它版本的PHP没有测试过,估计也有这个问题


Previous Comments:

[2012-08-16 09:02:11] 175384354 at qq dot com

Description:

php post

Test script:
---









$value){   //用foreach循环 
处理多个文件的上传
//2.判断文件是否上传错误

if($up_info[$k_name]['error']>0){
switch($up_info['error'][$i]){
case 1:
$err_info="上传的文件超过了 php.ini 中 
upload_max_filesize 选项限制的值";
break;
case 2:
$err_info="上传文件的大小超过了 HTML 表单中 
MAX_FILE_SIZE 选项指定的值";
break;
case 3:
$err_info="文件只有部分被上传";
break;
case 4:
$err_info="没有文件被上传";
break;
case 6:
$err_info="找不到临时文件夹";
break;
case 7:
$err_info="文件写入失败";
break;
default:
$err_info="未知的上传错误";
break;
}
continue($err_info);
}
$exten_name=pathinfo($up_info[$k_name]['name'],PATHINFO_EXTENSION);

do{
$main_name=date('YmHis'.'--'.rand(100,999));
$new_name=$main_name.'.'.$exten_name;
}while(file_exists($to_path.'/'.$new_name));


//6.判断是否是上传的文件,并执行上传

if(is_uploaded_file($up_info[$k_name]['tmp_name'])){


if(move_uploaded_file($up_info[$k_name]['tmp_name'],$upload_dir.'/'.$new_name)){
echo '上传成功!';
}else{
echo '上传文件移动失败!';
}
}else{
echo '文件不是上传的文件';
}

}   //for循环的括号

while ($file = readdir($handle)) {
   if(!is_dir($file) && !is_link($file)) {
  $filelist .= "".$file."";
  if ($DELETABLE)
$filelist .= " x";
  $filelist .= " ".date("d-m H:i", 
filemtime($upload_dir.$file))."";
  $filelist .="";
   }
}
echo "COOKIE:".$HTTP_COOKIE_VARS['myup']."";
echo  $filelist;

?>

Expected result:

PHP从PHP5.2.17到5.3.15 
都存在一个问题,会导致WEB服务器程序崩溃。
BUG描述:
服务器操作系统:windows server 2003
浏览器:MS IE 7.0
PHP使用方式:isapi

打开一个POST上传文件的PHP页面并上传一个文件,如果让这个上传页面闲置十几分钟以上,再次提交上传,会导致WEB服务器崩溃,而且没有任何提示。









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


Req #61066 [Com]: clones an object if using unserialize,spl_autoload_register

2012-08-16 Thread daniel dot beardsley at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=61066&edit=1

 ID: 61066
 Comment by: daniel dot beardsley at gmail dot com
 Reported by:arni at tsumi dot ru
 Summary:clones an object if using
 unserialize,spl_autoload_register
 Status: Open
 Type:   Feature/Change Request
 Package:SPL related
 Operating System:   FreeBSD
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

It's pretty difficult to understand this without a reproducable testcase, but 
it 
sounds very similar to this bug: https://bugs.php.net/bug.php?id=62836


Previous Comments:

[2012-02-12 22:37:21] arni at tsumi dot ru

Description:

clones an object if using unserialize,spl_autoload_register. This confuses the 
understanding of.

Test script:
---
spl_autoload_register(function($Class){
 /* Include file */
});

/* File Core.php */
class Core{
public $field;

public function __construct(){
$this->field = time();
}
}

/* File Lite.php */
class Lite{
protected $Core;

public function __construct($Core){
$this->Core = $Core;
}
}

$Core = new Core();

if(!$Lite = $Cache->Load('Lite')){
$Lite = new Lite(); // Ok ...
}


echo $Core->field; // Ok ...
echo $Lite->Core->field; // Out null.  $Core !=  $Core. $Core new object.


Expected result:

if($Core->field == $Lite->Core->field){
 echo 'Ok!';
}else{
 echo 'poorly';
}

Actual result:
--
$Core->field != $Lite->Core->field






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


Bug #62837 [Opn->Fbk]: ISAPI方式使用PHP,会导致web服务器崩溃.

2012-08-16 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=62837&edit=1

 ID: 62837
 Updated by: larue...@php.net
 Reported by:175384354 at qq dot com
 Summary:ISAPI方式使用PHP,会导致web服务器崩溃.
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   windows server 2003
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:

[2012-08-16 09:09:16] 175384354 at qq dot com

其它版本的PHP没有测试过,估计也有这个问题


[2012-08-16 09:02:11] 175384354 at qq dot com

Description:

php post

Test script:
---









$value){   //用foreach循环 
处理多个文件的上传
//2.判断文件是否上传错误

if($up_info[$k_name]['error']>0){
switch($up_info['error'][$i]){
case 1:
$err_info="上传的文件超过了 php.ini 中 
upload_max_filesize 选项限制的值";
break;
case 2:
$err_info="上传文件的大小超过了 HTML 表单中 
MAX_FILE_SIZE 选项指定的值";
break;
case 3:
$err_info="文件只有部分被上传";
break;
case 4:
$err_info="没有文件被上传";
break;
case 6:
$err_info="找不到临时文件夹";
break;
case 7:
$err_info="文件写入失败";
break;
default:
$err_info="未知的上传错误";
break;
}
continue($err_info);
}
$exten_name=pathinfo($up_info[$k_name]['name'],PATHINFO_EXTENSION);

do{
$main_name=date('YmHis'.'--'.rand(100,999));
$new_name=$main_name.'.'.$exten_name;
}while(file_exists($to_path.'/'.$new_name));


//6.判断是否是上传的文件,并执行上传

if(is_uploaded_file($up_info[$k_name]['tmp_name'])){


if(move_uploaded_file($up_info[$k_name]['tmp_name'],$upload_dir.'/'.$new_name)){
echo '上传成功!';
}else{
echo '上传文件移动失败!';
}
}else{
echo '文件不是上传的文件';
}

}   //for循环的括号

while ($file = readdir($handle)) {
   if(!is_dir($file) && !is_link($file)) {
  $filelist .= "".$file."";
  if ($DELETABLE)
$filelist .= " x";
  $filelist .= " ".date("d-m H:i", 
filemtime($upload_dir.$file))."";
  $filelist .="";
   }
}
echo "COOKIE:".$HTTP_COOKIE_VARS['myup']."";
echo  $filelist;

?>

Expected result:

PHP从PHP5.2.17到5.3.15 
都存在一个问题,会导致WEB服务器程序崩溃。
BUG描述:
服务器操作系统:windows server 2003
浏览器:MS IE 7.0
PHP使用方式:isapi

打开一个POST上传文件的PHP页面并上传一个文件,如果让这个上传页面闲置十几分钟以上,再次提交上传,会导致WEB服务器崩溃,而且没有任何提示。









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


[PHP-BUG] Bug #62838 [NEW]: enchant_dict_quick_check() destroys zval, but fails to initialized it

2012-08-16 Thread tony2...@php.net
From: tony2001
Operating system: 
PHP version:  5.4Git-2012-08-16 (Git)
Package:  Enchant related
Bug Type: Bug
Bug description:enchant_dict_quick_check() destroys zval, but fails to 
initialized it

Description:

enchant_dict_quick_check() destroys zval, but doesn't initialize it when
passing invalid enchant resource.
Initially reported by Mateusz Goik.

Test script:
---



Actual result:
--
/local/qa/5_4_ZTS/Zend/zend_hash.c(1055) : ht=0x7f6745191038 is
inconsistent


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



Bug #62838 [Opn->Asn]: enchant_dict_quick_check() destroys zval, but fails to initialized it

2012-08-16 Thread tony2001
Edit report at https://bugs.php.net/bug.php?id=62838&edit=1

 ID: 62838
 Updated by: tony2...@php.net
 Reported by:tony2...@php.net
 Summary:enchant_dict_quick_check() destroys zval, but fails
 to initialized it
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Enchant related
 PHP Version:5.4Git-2012-08-16 (Git)
-Assigned To:
+Assigned To:tony2001
 Block user comment: N
 Private report: N



Previous Comments:

[2012-08-16 10:28:36] tony2...@php.net

Description:

enchant_dict_quick_check() destroys zval, but doesn't initialize it when 
passing invalid enchant resource.
Initially reported by Mateusz Goik.

Test script:
---



Actual result:
--
/local/qa/5_4_ZTS/Zend/zend_hash.c(1055) : ht=0x7f6745191038 is inconsistent







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


Bug #62838 [Asn->Csd]: enchant_dict_quick_check() destroys zval, but fails to initialized it

2012-08-16 Thread tony2001
Edit report at https://bugs.php.net/bug.php?id=62838&edit=1

 ID: 62838
 Updated by: tony2...@php.net
 Reported by:tony2...@php.net
 Summary:enchant_dict_quick_check() destroys zval, but fails
 to initialized it
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Enchant related
 PHP Version:5.4Git-2012-08-16 (Git)
 Assigned To:tony2001
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-08-16 10:41:21] tony2...@php.net

Automatic comment on behalf of tony2001
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6
Log: Fixed bug #62838


[2012-08-16 10:40:59] tony2...@php.net

Automatic comment on behalf of tony2001
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6
Log: Fixed bug #62838


[2012-08-16 10:40:34] tony2...@php.net

Automatic comment on behalf of tony2001
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6
Log: Fixed bug #62838


[2012-08-16 10:28:36] tony2...@php.net

Description:

enchant_dict_quick_check() destroys zval, but doesn't initialize it when 
passing invalid enchant resource.
Initially reported by Mateusz Goik.

Test script:
---



Actual result:
--
/local/qa/5_4_ZTS/Zend/zend_hash.c(1055) : ht=0x7f6745191038 is inconsistent







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


[PHP-BUG] Bug #62839 [NEW]: curl_copy_handle segfault with CURLOPT_FILE

2012-08-16 Thread martin at mixotv dot com
From: martin at mixotv dot com
Operating system: Linux 3.4.8-1
PHP version:  5.4.5
Package:  cURL related
Bug Type: Bug
Bug description:curl_copy_handle segfault with CURLOPT_FILE

Description:

When using cURL with the option CURLOPT_FILE (write the result of the curl
request in a file), curl_copy_handle() causes a SEGFAULT.

I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).

I get the same results with a current ubuntu distribution.

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



Bug #62839 [Opn->Fbk]: curl_copy_handle segfault with CURLOPT_FILE

2012-08-16 Thread felipe
Edit report at https://bugs.php.net/bug.php?id=62839&edit=1

 ID: 62839
 Updated by: fel...@php.net
 Reported by:martin at mixotv dot com
 Summary:curl_copy_handle segfault with CURLOPT_FILE
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 3.4.8-1
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Try disabling xdebug.


Previous Comments:

[2012-08-16 13:58:36] martin at mixotv dot com

Description:

When using cURL with the option CURLOPT_FILE (write the result of the curl 
request in a file), curl_copy_handle() causes a SEGFAULT.

I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).

I get the same results with a current ubuntu distribution.

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


Bug #42330 [Com]: Type hinting based upon interfaces not working

2012-08-16 Thread jsuprock at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=42330&edit=1

 ID: 42330
 Comment by: jsuprock at gmail dot com
 Reported by:udo dot rader at bestsolution dot at
 Summary:Type hinting based upon interfaces not working
 Status: Wont fix
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.2.3
 Block user comment: N
 Private report: N

 New Comment:

Hi Derek,

Thank you for your responses; I ran into this same issue.  I hate to 
resurrect old tickets, but are you sure you want to leave this out?  

Here is my concern...  There is no point to have type hinting if object 
inheritance is not respected.  For example, let's say I have the following 
interface...

interface Comparable
{
public function gte(Comparable $value);
public function lte(Comparable $value);
public function eq(Comparable $value);
public function gt(Comparable $value);
public function lt(Comparable $value);
}

and now I have the following base classes...

class Orange implements Comparable
{
...
public function gte(Comparable $orange) { ... }
public function lte(Comparable $orange) { ... }
public function eq(Comparable $orange) { ... }
public function gt(Comparable $orange) { ... }
public function lt(Comparable $orange) { ... }
}

class Apple implements Comparable
{
...
public function gte(Comparable $apple) { ... }
public function lte(Comparable $apple) { ... }
public function eq(Comparable $apple) { ... }
public function gt(Comparable $apple) { ... }
public function lt(Comparable $apple) { ... }
}

Does it REALLY make sense to compare Apples to Oranges???


Kind regards,

John


Previous Comments:

[2007-08-17 18:16:37] udo dot rader at bestsolution dot at

Hmm, too bad.

The link you provided about the PDM meeting says "that most probably no 
language currently implements this correctly" is not true. 

Java for instance does this just nicely at least since 1.3.

With that limitation, the implementation of an AbstractDAO/AbstractFactory 
pattern will fail if type hinting is wanted, because transfer objects need to 
be identifyable by their common interface. Otherwise the entire interface thing 
in PHP does not make much sense, IMHO.

So anyhow, at least the error message should be changed to be more clear.


[2007-08-17 17:47:13] der...@php.net

PHP does not implement inheritance checks for typehinted arguments. Please also 
refer to the PDM meeting notes, where this was discussed: 
http://www.php.net/~derick/meeting-notes.html#implement-inheritance-rules-for-type-hints


[2007-08-17 17:31:48] udo dot rader at bestsolution dot at

Description:

When using type hinting with interfaces it fails to recognoize classes 
implementing the interface as "compatible".

Reproduce code:
---
abstract class Foo  {
abstract public function saySomething( IBar $what );
abstract public function saySomethingElse( IBar $what );
}
class BarDAO extends Foo {
function saySomething( IBar $what ) {
echo $what->getMessage();
}
function saySomethingElse( BarTransfer $what ) {
echo $what->getMessage();
}
}
interface IBar {
function getMessage();
}
class BarTransfer implements IBar {
function getMessage() {
return "Hello from BarTransfer";
}
}
$barDAO = new BarDAO();
$barTransfer = new BarTransfer();
$barDAO->saySomething( $barTransfer );
$barDAO->saySomethingElse( $barTransfer );


Expected result:

The expected result should be that no compiler error occurs and that the script 
runs.

Actual result:
--
The PHP interpreter gives this error:

Fatal error: Declaration of BarDAO::saySomethingElse() must be compatible with 
that of Foo::saySomethingElse()

But, IMHO, BarTransfer can hardly be more "compatible" with IBar.







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


Bug #42330 [Com]: Type hinting based upon interfaces not working

2012-08-16 Thread jsuprock at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=42330&edit=1

 ID: 42330
 Comment by: jsuprock at gmail dot com
 Reported by:udo dot rader at bestsolution dot at
 Summary:Type hinting based upon interfaces not working
 Status: Wont fix
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.2.3
 Block user comment: N
 Private report: N

 New Comment:

Derick,

  I'm sorry I misspelled your name.

Sincerely,

John S


Previous Comments:

[2012-08-16 14:13:47] jsuprock at gmail dot com

Hi Derek,

Thank you for your responses; I ran into this same issue.  I hate to 
resurrect old tickets, but are you sure you want to leave this out?  

Here is my concern...  There is no point to have type hinting if object 
inheritance is not respected.  For example, let's say I have the following 
interface...

interface Comparable
{
public function gte(Comparable $value);
public function lte(Comparable $value);
public function eq(Comparable $value);
public function gt(Comparable $value);
public function lt(Comparable $value);
}

and now I have the following base classes...

class Orange implements Comparable
{
...
public function gte(Comparable $orange) { ... }
public function lte(Comparable $orange) { ... }
public function eq(Comparable $orange) { ... }
public function gt(Comparable $orange) { ... }
public function lt(Comparable $orange) { ... }
}

class Apple implements Comparable
{
...
public function gte(Comparable $apple) { ... }
public function lte(Comparable $apple) { ... }
public function eq(Comparable $apple) { ... }
public function gt(Comparable $apple) { ... }
public function lt(Comparable $apple) { ... }
}

Does it REALLY make sense to compare Apples to Oranges???


Kind regards,

John


[2007-08-17 18:16:37] udo dot rader at bestsolution dot at

Hmm, too bad.

The link you provided about the PDM meeting says "that most probably no 
language currently implements this correctly" is not true. 

Java for instance does this just nicely at least since 1.3.

With that limitation, the implementation of an AbstractDAO/AbstractFactory 
pattern will fail if type hinting is wanted, because transfer objects need to 
be identifyable by their common interface. Otherwise the entire interface thing 
in PHP does not make much sense, IMHO.

So anyhow, at least the error message should be changed to be more clear.


[2007-08-17 17:47:13] der...@php.net

PHP does not implement inheritance checks for typehinted arguments. Please also 
refer to the PDM meeting notes, where this was discussed: 
http://www.php.net/~derick/meeting-notes.html#implement-inheritance-rules-for-type-hints


[2007-08-17 17:31:48] udo dot rader at bestsolution dot at

Description:

When using type hinting with interfaces it fails to recognoize classes 
implementing the interface as "compatible".

Reproduce code:
---
abstract class Foo  {
abstract public function saySomething( IBar $what );
abstract public function saySomethingElse( IBar $what );
}
class BarDAO extends Foo {
function saySomething( IBar $what ) {
echo $what->getMessage();
}
function saySomethingElse( BarTransfer $what ) {
echo $what->getMessage();
}
}
interface IBar {
function getMessage();
}
class BarTransfer implements IBar {
function getMessage() {
return "Hello from BarTransfer";
}
}
$barDAO = new BarDAO();
$barTransfer = new BarTransfer();
$barDAO->saySomething( $barTransfer );
$barDAO->saySomethingElse( $barTransfer );


Expected result:

The expected result should be that no compiler error occurs and that the script 
runs.

Actual result:
--
The PHP interpreter gives this error:

Fatal error: Declaration of BarDAO::saySomethingElse() must be compatible with 
that of Foo::saySomethingElse()

But, IMHO, BarTransfer can hardly be more "compatible" with IBar.







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


Bug #62839 [Fbk->Opn]: curl_copy_handle segfault with CURLOPT_FILE

2012-08-16 Thread martin at mixotv dot com
Edit report at https://bugs.php.net/bug.php?id=62839&edit=1

 ID: 62839
 User updated by:martin at mixotv dot com
 Reported by:martin at mixotv dot com
 Summary:curl_copy_handle segfault with CURLOPT_FILE
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 3.4.8-1
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Hi Felipe,

Here is the backtrace without Xdebug:

Program received signal SIGSEGV, Segmentation fault.
#0  0x75ed9f46 in ?? () from /usr/lib/php/modules/curl.so
#1  0x006dae02 in ?? ()
#2  0x006946ff in execute ()
#3  0x006355d9 in zend_execute_scripts ()
#4  0x005d5393 in php_execute_script ()
#5  0x006dd433 in ?? ()
#6  0x0042601a in ?? ()
#7  0x7692d725 in __libc_start_main () from /lib/libc.so.6
#8  0x004260ad in _start ()


Previous Comments:

[2012-08-16 14:09:36] fel...@php.net

Try disabling xdebug.


[2012-08-16 13:58:36] martin at mixotv dot com

Description:

When using cURL with the option CURLOPT_FILE (write the result of the curl 
request in a file), curl_copy_handle() causes a SEGFAULT.

I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).

I get the same results with a current ubuntu distribution.

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


[PHP-BUG] Req #62840 [NEW]: Add sort flag to ArrayObject::ksort

2012-08-16 Thread bert at becoded dot be
From: bert at becoded dot be
Operating system: 
PHP version:  5.4.5
Package:  SPL related
Bug Type: Feature/Change Request
Bug description:Add sort flag to ArrayObject::ksort

Description:

When mixing numeric and strings for the keys, you can get unexpected
results. With the ksort, you can specify a sort flag (see the flags on
http://www.php.net/manual/en/function.sort.php). Using that, you are able
to change the sort behaviour.
It would be great if we could specify the same sort flag for
ArrayObject::ksort.
So instead of public void ArrayObject::ksort ( void ) it would be public
void ArrayObject::ksort ( [ int $sort_flags = SORT_REGULAR ])

Test script:
---
 'Value 3', 'Unknown key 1', 'key_1' => 'Value 1',
'key_2' => 'Value 2', 'key_0' => 'Value 0', 'Unknown key 2');
ksort($list);
var_dump($list);
ksort($list, SORT_STRING);
var_dump($list);

$list = new ArrayObject();
$list->offsetSet('key_3', 'Value 3');
$list->append('Unknown key 1');
$list->offsetSet('key_1', 'Value 1');
$list->offsetSet('key_2', 'Value 2');
$list->offsetSet('key_0', 'Value 0');
$list->append('Unknown key 2');
$list->ksort();
//$list->ksort(SORT_STRING);
var_dump($list);

Expected result:

If $list->ksort(SORT_STRING) would work, then I would expect
object(ArrayObject)[1689]
  string 'Unknown key 1' (length=13)
  string 'Unknown key 2' (length=13)
  public 'key_0' => string 'Value 0' (length=7)
  public 'key_1' => string 'Value 1' (length=7)
  public 'key_2' => string 'Value 2' (length=7)
  public 'key_3' => string 'Value 3' (length=7)



Actual result:
--
//ksort
array (size=6)
  'key_0' => string 'Value 0' (length=7)
  'key_1' => string 'Value 1' (length=7)
  0 => string 'Unknown key 1' (length=13)
  'key_2' => string 'Value 2' (length=7)
  'key_3' => string 'Value 3' (length=7)
  1 => string 'Unknown key 2' (length=13)

//ksort with sort flag SORT_STRING
array (size=6)
  0 => string 'Unknown key 1' (length=13)
  1 => string 'Unknown key 2' (length=13)
  'key_0' => string 'Value 0' (length=7)
  'key_1' => string 'Value 1' (length=7)
  'key_2' => string 'Value 2' (length=7)
  'key_3' => string 'Value 3' (length=7)

//ArrayObject::ksort
object(ArrayObject)[1689]
  public 'key_0' => string 'Value 0' (length=7)
  public 'key_1' => string 'Value 1' (length=7)
  string 'Unknown key 1' (length=13)
  public 'key_2' => string 'Value 2' (length=7)
  public 'key_3' => string 'Value 3' (length=7)
  string 'Unknown key 2' (length=13)

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



Req #49576 [Com]: Filter var for validating email is not validating emails correctly

2012-08-16 Thread damien dot regad at merckgroup dot com
Edit report at https://bugs.php.net/bug.php?id=49576&edit=1

 ID: 49576
 Comment by: damien dot regad at merckgroup dot com
 Reported by:mparkin at de-facto dot com
 Summary:Filter var for validating email is not validating
 emails correctly
 Status: Feedback
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*
 Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Going back to what grangeway posted 2 years ago, the filter still does not 
accept single-domain addresses:

php > var_export( filter_var( 'user@localhost', FILTER_VALIDATE_EMAIL ) );
false

I tested with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) on Ubuntu 12.04

However, if I understand well the ABNF[1] in the RFC specification [2], this 
should in fact be allowed (see sections 3.4.1 and 3.2.3 for details):

addr-spec   =   local-part "@" domain
domain  =   dot-atom / domain-literal / obs-domain
dot-atom=   [CFWS] dot-atom-text [CFWS]
dot-atom-text   =   1*atext *("." 1*atext)

The last bit (dot-atom-text) says that there must be 1 or more chars followed 
by zero or more groups of ("." followed by 1 or more chars).

It would be nice to have this fixed. Thanks in advance !

[1] http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
[2] http://tools.ietf.org/html/rfc5322


Previous Comments:

[2010-08-17 21:34:47] michael at squiloople dot com

You might find this useful, taken directly from my article on E-mail address 
validation, in deciding whether or not to allow single-label domain names:

"There is some confusion over whether or not single-label domain names are 
allowed — michael@squiloople, for example. People often cite the following 
section in RFC 5321 to argue that they are not allowed:

"'Only resolvable, fully-qualified domain names (FQDNs) are permitted when 
domain names are used in SMTP. In other words, names that can be resolved to MX 
RRs or address (i.e., A or ) RRs (as discussed in Section 5) are permitted, 
as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. 
Local nicknames or unqualified names MUST NOT be used.'

"The implicit premise here is that TLD-only domain names cannot be resolved to 
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and getmxrr('ai', 
$array) return true, showing that single-label domain names can, and do, 
resolve 
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain. 
Therefore, michael@squiloople is valid (although in this example, 
‘squiloople’ 
is not a TLD).

"And as an extra note, here’s another excerpt from RFC 5321:

"'In the case of a top-level domain used by itself in an email address, a 
single 
string is used without any dots.'"


[2010-08-15 02:09:23] paj...@php.net

Have you tried with 5.2.14 or 5.3.3?


[2010-08-14 21:10:33] grangeway at hotmail dot com

Additionally:

1) at the moment, I believe the current regex does not allow fred@com as an 
email address. Albeit, it's going back almost 10 years now - I'm pretty sure  I 
received an email from someone @tld, complaining that a regex  did not allow 
their valid email address to sign up.

2) The issue the user hit is the phpmailer class contains the following code to 
validate email addresses against FILTER_VALIDATE_EMAIL regardless of whether 
SMTP or mail() is the sending method.

550  public static function ValidateAddress($address) {
551if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else 
 regex


[2010-08-14 20:48:24] ka...@php.net

Re-opened, the last comment seems quite valid to me, don't you think so Rasmus?


[2010-08-05 16:41:58] alexsander dot rosa at gmail dot com

The format "username@box" for local networks IS allowed when the mail() method 
is used. I quote RFC 5321: "local aliases MUST NOT appear in any SMTP 
transaction." They say NOTHING about mail() method in the RFC.




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


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


Req #43219 [Com]: connection_status() can function properly without output

2012-08-16 Thread danclax at rambler dot ru
Edit report at https://bugs.php.net/bug.php?id=43219&edit=1

 ID: 43219
 Comment by: danclax at rambler dot ru
 Reported by:php at alterego dot dp dot ua
 Summary:connection_status() can function properly without
 output
 Status: Open
 Type:   Feature/Change Request
 Package:Output Control
 Operating System:   Any
 PHP Version:5.2.5RC2
 Block user comment: N
 Private report: N

 New Comment:

PHP 5.3.3, Apache 2.2.15, CentOS 6.2 x86 - issue reproducible! I can't believe 
it! Bug persists 5 years. For me it's vital feature.


Previous Comments:

[2007-11-08 23:28:52] php at alterego dot dp dot ua

Description:

Please regard this comment seriously, it really contains information on how to 
fix 25266, 22072, 30301 and many other (NOT bogus) bugs under Apache SAPI.

>From bug 25266 comment by il...@php.net:
> Apache provides a way for PHP to detect if connection was 
> aborted ONLY and ONLY when PHP is either reading data from 
> the user or writing back data.

That is not true.

This link contains description and code (mod_perl) on how to detect 
disconnection without flushing data:
http://www.webreference.com/programming/perl/cookbook/chap4/5.html

My untidy but WORKING solution was to add code given below to sapi_apache_flush 
function and call flush() function before connection_aborted() checks WITHOUT 
any output. Of course, it would be perfectly logical to add it to 
connection_aborted function itself, but I could not find any way to call 
SAPI-specific function from core.

Working code is:
int fd;
struct timeval tv = {0,0};
fd_set set;

if (server_context) {
request_rec *r = SG(server_context);

fd = ap_bfileno(r->connection->client, B_WR);

if (fd >= 0) {
FD_ZERO(&set);
FD_SET(fd, &set);
if (select(fd + 1, &set, NULL, NULL, &tv) >= 0 && FD_ISSET(fd, &set))
{
php_handle_aborted_connection();
}
}
}








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


Req #49576 [Fbk->Wfx]: Filter var for validating email is not validating emails correctly

2012-08-16 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=49576&edit=1

 ID: 49576
 Updated by: ras...@php.net
 Reported by:mparkin at de-facto dot com
 Summary:Filter var for validating email is not validating
 emails correctly
-Status: Feedback
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*
 Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

I am not disagreeing that local domains are invalid per the RFC, but I do think 
that in most cases Web apps probably don't have a use for these cases since 
they 
don't resolve outside of the local environment. I suppose some Intranet web 
apps 
would find this useful, but the bulk of Internet apps would need to add a 
second 
check to make sure that it wasn't a non external SMTP-able address that 
validated. I would suggest that the few cases where you do want local single-
domain addresses to validate you add a simple check in front of filter_var. 
They 
are easy to check for.


Previous Comments:

[2012-08-16 16:48:28] damien dot regad at merckgroup dot com

Going back to what grangeway posted 2 years ago, the filter still does not 
accept single-domain addresses:

php > var_export( filter_var( 'user@localhost', FILTER_VALIDATE_EMAIL ) );
false

I tested with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) on Ubuntu 12.04

However, if I understand well the ABNF[1] in the RFC specification [2], this 
should in fact be allowed (see sections 3.4.1 and 3.2.3 for details):

addr-spec   =   local-part "@" domain
domain  =   dot-atom / domain-literal / obs-domain
dot-atom=   [CFWS] dot-atom-text [CFWS]
dot-atom-text   =   1*atext *("." 1*atext)

The last bit (dot-atom-text) says that there must be 1 or more chars followed 
by zero or more groups of ("." followed by 1 or more chars).

It would be nice to have this fixed. Thanks in advance !

[1] http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
[2] http://tools.ietf.org/html/rfc5322


[2010-08-17 21:34:47] michael at squiloople dot com

You might find this useful, taken directly from my article on E-mail address 
validation, in deciding whether or not to allow single-label domain names:

"There is some confusion over whether or not single-label domain names are 
allowed — michael@squiloople, for example. People often cite the following 
section in RFC 5321 to argue that they are not allowed:

"'Only resolvable, fully-qualified domain names (FQDNs) are permitted when 
domain names are used in SMTP. In other words, names that can be resolved to MX 
RRs or address (i.e., A or ) RRs (as discussed in Section 5) are permitted, 
as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. 
Local nicknames or unqualified names MUST NOT be used.'

"The implicit premise here is that TLD-only domain names cannot be resolved to 
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and getmxrr('ai', 
$array) return true, showing that single-label domain names can, and do, 
resolve 
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain. 
Therefore, michael@squiloople is valid (although in this example, 
‘squiloople’ 
is not a TLD).

"And as an extra note, here’s another excerpt from RFC 5321:

"'In the case of a top-level domain used by itself in an email address, a 
single 
string is used without any dots.'"


[2010-08-15 02:09:23] paj...@php.net

Have you tried with 5.2.14 or 5.3.3?


[2010-08-14 21:10:33] grangeway at hotmail dot com

Additionally:

1) at the moment, I believe the current regex does not allow fred@com as an 
email address. Albeit, it's going back almost 10 years now - I'm pretty sure  I 
received an email from someone @tld, complaining that a regex  did not allow 
their valid email address to sign up.

2) The issue the user hit is the phpmailer class contains the following code to 
validate email addresses against FILTER_VALIDATE_EMAIL regardless of whether 
SMTP or mail() is the sending method.

550  public static function ValidateAddress($address) {
551if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else 
 regex


[2010-08-14 20:48:24] ka...@php.net

Re-opened, the last comment seems quite valid to me, don't you think so Rasmus?




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:/

Bug #62836 [Com]: Seg fault or broken object references on unserialize()

2012-08-16 Thread james at ifixit dot com
Edit report at https://bugs.php.net/bug.php?id=62836&edit=1

 ID: 62836
 Comment by: james at ifixit dot com
 Reported by:daniel dot beardsley at gmail dot com
 Summary:Seg fault or broken object references on
 unserialize()
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   CentOS
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

I've just reproduced this on a build from master, at commit 
b5305d267b6c3b1b09ab0ba4ecf4f66edc5d4077 .

root 11:37:49 serialize > php --version
PHP 5.5.0-dev (cli) (built: Aug 16 2012 11:37:55)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
root 11:39:37 serialize > ./run_test.sh
./run_test.sh: line 3:  2267 Segmentation fault  php 
unserialize_autoload.php > after.out
Original ==
in autoload: A
in autoload: B
object(A)#1 (4) {
  ["b"]=>
  object(B)#2 (0) {
  }
  ["b1"]=>
  object(B)#2 (0) {
  }
  ["c"]=>
  object(B)#3 (0) {
  }
  ["c1"]=>
  object(B)#3 (0) {
  }
}

Unserialized ==
in autoload: A
in autoload: B
object(A)#1 (4) {
  ["b"]=>
  object(B)#2 (0) {
  }
  ["b1"]=>
  object(B)#2 (0) {
  }
  ["c"]=>
  object(B)#3 (0) {
  }
  ["c1"]=>
  NULL
}

Diff ==
14,15c14
<   object(B)#3 (0) {
<   }
---
>   NULL
FAILED 

I built php with the following configure line:

./configure  --host=i686-redhat-linux-gnu --build=i686-redhat-linux-gnu \
--target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr \
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share \
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec \
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man \
--infodir=/usr/share/info --with-libdir=lib64 --with-config-file-path=/etc \
--with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic \
--disable-rpath --with-bz2 --with-curl --with-exec-dir=/usr/bin \
--with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf \
--without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr \
--with-openssl --with-pcre-regex=/usr --with-zlib --with-layout=GNU \
--enable-exif --enable-ftp --enable-magic-quotes --enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-wddx \
--with-kerberos  --enable-shmop --enable-calendar \
--without-sqlite --with-libxml-dir=/usr \
--enable-pcntl --with-imap=/usr/lib64 \
--with-imap-ssl=/usr/local/ssl/include/openssl --enable-mbstring \
--enable-mbregex --with-gd --enable-bcmath --with-xmlrpc=shared \
--with-mysql=mysqlnd --with-mysqli=mysqlnd \
--enable-dom --enable-soap=shared --with-xsl=shared,/usr \
--enable-xmlreader=shared --enable-xmlwriter=shared --with-readline \
--with-mcrypt=/usr/local/include/mcrypt --with-mhash --with-tidy=shared,/usr \
--enable-sigchild --enable-intl --with-apxs2=/usr/sbin/apxs \
--enable-fpm --with-fpm-user=apache --with-fpm-group=apache


Previous Comments:

[2012-08-16 08:59:19] daniel dot beardsley at gmail dot com

Description:

Occurs on php 5.4.0, but not on 5.3 (I'll try on other versions soon).
Please run this test from /tmp/serialize/run_tests.sh (see bottom for 
explanation)

## Description ##

If calling unserialize() somehow calls back into user code (i.e. autoloading a
class while unserializing it) and user code does another unserialize() (no 
matter what it is), object references in the outer unserialization process 
won't 
be restored correctly. Sometimes the outer call can result in a Segmentation 
Fault instead of just broken references.

In particular, object refrerences will often be replaced with a seemingly random
value from your serialized object graph (or NULL).

The call stack at the time of the problem looks like this:

  #0 /tmp/serialize/setup.php(6): unserialize('i:4');
  #1 [internal function]: __autoload('A')
  #2 /tmp/serialize/unserialize_autoload.php(4): unserialize('O:1:"A":4:
{s:1:...')
  #3 {main}

The unserialize call in frame #2 returns incorrect results because of the 
"recursive" unserialize call in frame #0.

Note:
For reasons that completely escape me, this code seems dependent on the literal 
path it's run from.  Some paths hide the bug, some cause failure, and some 
cause 
a SegFault.  It's consistent on a per-path basis, but I found no pattern.  

Test script:
---
https://gist.github.com/3353895

Expected result:

Before and After output should be the same. Last line of output should read: 
"Passed, no differences"

Before Serialization:
class A#1 (4) {
  public $b =>
  class B#2 (0) {
  }
  public $b1 =>
  class B#2 (0) {
  }
  public $c =>
  class B#3 (0) {
  }
  public $c1 =>
  class B#3 (0) {
  }
}

Actual result:
--
After Serialization:
class A#1 (4) {
  public $b =>
  class B#2

Bug #62839 [Asn->Csd]: curl_copy_handle segfault with CURLOPT_FILE

2012-08-16 Thread pierrick
Edit report at https://bugs.php.net/bug.php?id=62839&edit=1

 ID: 62839
 Updated by: pierr...@php.net
 Reported by:martin at mixotv dot com
 Summary:curl_copy_handle segfault with CURLOPT_FILE
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 3.4.8-1
 PHP Version:5.4.5
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

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




Previous Comments:

[2012-08-16 18:52:50] pierr...@php.net

Automatic comment on behalf of pierrick
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=9cf0139460c7531ebe8fdd523ba6cf7067a7f282
Log: Fixed bug #62839


[2012-08-16 14:17:49] martin at mixotv dot com

Hi Felipe,

Here is the backtrace without Xdebug:

Program received signal SIGSEGV, Segmentation fault.
#0  0x75ed9f46 in ?? () from /usr/lib/php/modules/curl.so
#1  0x006dae02 in ?? ()
#2  0x006946ff in execute ()
#3  0x006355d9 in zend_execute_scripts ()
#4  0x005d5393 in php_execute_script ()
#5  0x006dd433 in ?? ()
#6  0x0042601a in ?? ()
#7  0x7692d725 in __libc_start_main () from /lib/libc.so.6
#8  0x004260ad in _start ()


[2012-08-16 14:09:36] fel...@php.net

Try disabling xdebug.


[2012-08-16 13:58:36] martin at mixotv dot com

Description:

When using cURL with the option CURLOPT_FILE (write the result of the curl 
request in a file), curl_copy_handle() causes a SEGFAULT.

I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).

I get the same results with a current ubuntu distribution.

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


Req #49576 [Com]: Filter var for validating email is not validating emails correctly

2012-08-16 Thread le...@php.net
Edit report at https://bugs.php.net/bug.php?id=49576&edit=1

 ID: 49576
 Comment by: le...@php.net
 Reported by:mparkin at de-facto dot com
 Summary:Filter var for validating email is not validating
 emails correctly
 Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*
 Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Honestly, why can't we have an option to FILTER_VALIDATE_EMAIL to not require a 
TLD?  I do write intranet applications and it would be useful. Adding an option 
does not break BC at all.


Previous Comments:

[2012-08-16 18:01:44] ras...@php.net

I am not disagreeing that local domains are invalid per the RFC, but I do think 
that in most cases Web apps probably don't have a use for these cases since 
they 
don't resolve outside of the local environment. I suppose some Intranet web 
apps 
would find this useful, but the bulk of Internet apps would need to add a 
second 
check to make sure that it wasn't a non external SMTP-able address that 
validated. I would suggest that the few cases where you do want local single-
domain addresses to validate you add a simple check in front of filter_var. 
They 
are easy to check for.


[2012-08-16 16:48:28] damien dot regad at merckgroup dot com

Going back to what grangeway posted 2 years ago, the filter still does not 
accept single-domain addresses:

php > var_export( filter_var( 'user@localhost', FILTER_VALIDATE_EMAIL ) );
false

I tested with PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) on Ubuntu 12.04

However, if I understand well the ABNF[1] in the RFC specification [2], this 
should in fact be allowed (see sections 3.4.1 and 3.2.3 for details):

addr-spec   =   local-part "@" domain
domain  =   dot-atom / domain-literal / obs-domain
dot-atom=   [CFWS] dot-atom-text [CFWS]
dot-atom-text   =   1*atext *("." 1*atext)

The last bit (dot-atom-text) says that there must be 1 or more chars followed 
by zero or more groups of ("." followed by 1 or more chars).

It would be nice to have this fixed. Thanks in advance !

[1] http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
[2] http://tools.ietf.org/html/rfc5322


[2010-08-17 21:34:47] michael at squiloople dot com

You might find this useful, taken directly from my article on E-mail address 
validation, in deciding whether or not to allow single-label domain names:

"There is some confusion over whether or not single-label domain names are 
allowed — michael@squiloople, for example. People often cite the following 
section in RFC 5321 to argue that they are not allowed:

"'Only resolvable, fully-qualified domain names (FQDNs) are permitted when 
domain names are used in SMTP. In other words, names that can be resolved to MX 
RRs or address (i.e., A or ) RRs (as discussed in Section 5) are permitted, 
as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. 
Local nicknames or unqualified names MUST NOT be used.'

"The implicit premise here is that TLD-only domain names cannot be resolved to 
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and getmxrr('ai', 
$array) return true, showing that single-label domain names can, and do, 
resolve 
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain. 
Therefore, michael@squiloople is valid (although in this example, 
‘squiloople’ 
is not a TLD).

"And as an extra note, here’s another excerpt from RFC 5321:

"'In the case of a top-level domain used by itself in an email address, a 
single 
string is used without any dots.'"


[2010-08-15 02:09:23] paj...@php.net

Have you tried with 5.2.14 or 5.3.3?


[2010-08-14 21:10:33] grangeway at hotmail dot com

Additionally:

1) at the moment, I believe the current regex does not allow fred@com as an 
email address. Albeit, it's going back almost 10 years now - I'm pretty sure  I 
received an email from someone @tld, complaining that a regex  did not allow 
their valid email address to sign up.

2) The issue the user hit is the phpmailer class contains the following code to 
validate email addresses against FILTER_VALIDATE_EMAIL regardless of whether 
SMTP or mail() is the sending method.

550  public static function ValidateAddress($address) {
551if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else 
 regex




The remainder of the comments for this report are too long. To vi

[PHP-BUG] Bug #62841 [NEW]: ora11g doesn't work

2012-08-16 Thread altieresdelsent at gmail dot com
From: altieresdelsent at gmail dot com
Operating system: Windows
PHP version:  5.4.6
Package:  OCI8 related
Bug Type: Bug
Bug description:ora11g doesn't work 

Description:

I was using php 5.3 with oracle client 11g and everything works fine. I
have a wep app already in production with php5.3. I tried upgrade to
php5.4, so I install in another folder XAMPP 1.8 who uses php 5.4. I tried
everything to make oracle works, but I cannot connect in the database. Its
really strange because in the same machine with the same remote database
php 5.3 works just fine.
I am using in php 5.3 o php_oci8.dll with oracle client 11g
and with php5.4 I tried use php_oci8.dll. The error is:
ORA-12154: TNS:could not resolve the connect identifier specified
after I tried php_oci8_11g.dll and the the error is:
ORA-24315: illegal attribute type

I on a Windows Vista 64bit Machine,
Both php are 32bis,
oracle client is 32bits
The database is in another machine.

I think that everything that you need to simulate the problem is install
XAMPP 1.8, enable php_oci8.dll and try run the test script.


Test script:
---
print_r(get_loaded_extensions());
print_r(get_extension_funcs('oci8'));
echo system('env');
echo "Client Version: " . oci_client_version(); 
print_r(oci_pconnect(DBUSER, DBPASSWORD, DBTNS));

print_r(oci_error());
die();



Expected result:

I was expecting that the oci_pconnect works, because the same script with
php 5.3, works.

Actual result:
--
Array
(
[0] => Core
[1] => bcmath
[2] => calendar
[3] => com_dotnet
[4] => ctype
[5] => date
[6] => ereg
[7] => filter
[8] => ftp
[9] => hash
[10] => iconv
[11] => json
[12] => mcrypt
[13] => SPL
[14] => odbc
[15] => pcre
[16] => Reflection
[17] => session
[18] => standard
[19] => mysqlnd
[20] => tokenizer
[21] => zip
[22] => zlib
[23] => libxml
[24] => dom
[25] => PDO
[26] => bz2
[27] => SimpleXML
[28] => wddx
[29] => xml
[30] => xmlreader
[31] => xmlwriter
[32] => apache2handler
[33] => Phar
[34] => mbstring
[35] => exif
[36] => gd
[37] => gettext
[38] => mysql
[39] => mysqli
[40] => oci8
[41] => pdo_mysql
[42] => pdo_sqlite
[43] => soap
[44] => sockets
[45] => sqlite3
[46] => xmlrpc
[47] => xsl
[48] => mhash
)
Array
(
[0] => oci_define_by_name
[1] => oci_bind_by_name
[2] => oci_bind_array_by_name
[3] => oci_field_is_null
[4] => oci_field_name
[5] => oci_field_size
[6] => oci_field_scale
[7] => oci_field_precision
[8] => oci_field_type
[9] => oci_field_type_raw
[10] => oci_execute
[11] => oci_cancel
[12] => oci_fetch
[13] => oci_fetch_object
[14] => oci_fetch_row
[15] => oci_fetch_assoc
[16] => oci_fetch_array
[17] => ocifetchinto
[18] => oci_fetch_all
[19] => oci_free_statement
[20] => oci_internal_debug
[21] => oci_num_fields
[22] => oci_parse
[23] => oci_new_cursor
[24] => oci_result
[25] => oci_client_version
[26] => oci_server_version
[27] => oci_statement_type
[28] => oci_num_rows
[29] => oci_close
[30] => oci_connect
[31] => oci_new_connect
[32] => oci_pconnect
[33] => oci_error
[34] => oci_free_descriptor
[35] => oci_lob_save
[36] => oci_lob_import
[37] => oci_lob_size
[38] => oci_lob_load
[39] => oci_lob_read
[40] => oci_lob_eof
[41] => oci_lob_tell
[42] => oci_lob_truncate
[43] => oci_lob_erase
[44] => oci_lob_flush
[45] => ocisetbufferinglob
[46] => ocigetbufferinglob
[47] => oci_lob_is_equal
[48] => oci_lob_rewind
[49] => oci_lob_write
[50] => oci_lob_append
[51] => oci_lob_copy
[52] => oci_lob_export
[53] => oci_lob_seek
[54] => oci_commit
[55] => oci_rollback
[56] => oci_new_descriptor
[57] => oci_set_prefetch
[58] => oci_set_client_identifier
[59] => oci_set_edition
[60] => oci_set_module_name
[61] => oci_set_action
[62] => oci_set_client_info
[63] => oci_password_change
[64] => oci_free_collection
[65] => oci_collection_append
[66] => oci_collection_element_get
[67] => oci_collection_element_assign
[68] => oci_collection_assign
[69] => oci_collection_size
[70] => oci_collection_max
[71] => oci_collection_trim
[72] => oci_new_collection
[73] => oci_free_cursor
[74] => ocifreecursor
[75] => ocibindbyname
[76] => ocidefinebyname
[77] => ocicolumnisnull
[78] => ocicolumnname
[79] => ocicolumnsize
[80] => ocicolumnscale
[81] => ocicolumnprecision
[82] => ocicolumntype
[83] => ocicolumntyperaw
[84] => ociexecute
[85] => ocicancel
[86] => ocifetch
[87] => ocifetchstatement
[88] => ocifreestat

Bug #62829 [Com]: stdint.h included on platform where HAVE_STDINT_H is not set

2012-08-16 Thread Gillingham at bikezen dot net
Edit report at https://bugs.php.net/bug.php?id=62829&edit=1

 ID: 62829
 Comment by: Gillingham at bikezen dot net
 Reported by:philipm at sybase dot com
 Summary:stdint.h included on platform where HAVE_STDINT_H is
 not set
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Solaris 9
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Note that this bug still exists in 5.4.6 as well.


Previous Comments:

[2012-08-16 18:35:48] fel...@php.net

Automatic comment on behalf of felipe...@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2e1d31d123ea5f310719c6c3c51587834907b7bf
Log: - Fixed bug #62829 (stdint.h included on platform where HAVE_STDINT_H is 
not set)


[2012-08-15 16:06:58] philipm at sybase dot com

Description:

Configuring on Solaris 9 results in HAVE_STDINT_H undefined in 
main/php_config.h.  Nevertheless, there is an include error when running make.  
Surrounding the offending line with #if HAVE_STDINT_H is sufficient to resolve 
the compile error.  This started in PHP 5.4.0 and is still an issue in 5.4.5.

/bin/bash /usr/local/php/php-5.4.1/libtool --silent --preserve-dup-deps --
mode=compile cc  -Isapi/cli/ -I/usr/local/php/php-5.4.1/sapi/cli/ 
-DPHP_ATOM_INC 
-I/usr/local/php/php-5.4.1/include -I/usr/local/php/php-5.4.1/main -
I/usr/local/php/php-5.4.1 -I/usr/local/php/php-5.4.1/ext/date/lib -
I/usr/local/php/php-5.4.1/ext/ereg/regex -I/usr/local/php/php-5.4.1/TSRM -
I/usr/local/php/php-5.4.1/Zend  -D_POSIX_PTHREAD_SEMANTICS  -m64 -xmemalign=8s  
-c /usr/local/php/php-5.4.1/sapi/cli/php_http_parser.c -o 
sapi/cli/php_http_parser.lo 
"/usr/local/php/php-5.4.1/sapi/cli/php_http_parser.h", line 35: cannot find 
include file: 
cc: acomp failed for /usr/local/php/php-5.4.1/sapi/cli/php_http_parser.c
make: *** [sapi/cli/php_http_parser.lo] Error 1


Test script:
---
./configure
make

Expected result:

If HAVE_STDINT_H is not set, then stdint.h should not be included.







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


Bug #62829 [Opn->Csd]: stdint.h included on platform where HAVE_STDINT_H is not set

2012-08-16 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=62829&edit=1

 ID: 62829
 Updated by: ras...@php.net
 Reported by:philipm at sybase dot com
 Summary:stdint.h included on platform where HAVE_STDINT_H is
 not set
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Solaris 9
 PHP Version:5.4.5
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Yes, we know, the fix went in too late to be in 5.4.6. It will be in 5.4.7.


Previous Comments:

[2012-08-17 00:00:41] Gillingham at bikezen dot net

Note that this bug still exists in 5.4.6 as well.


[2012-08-16 18:35:48] fel...@php.net

Automatic comment on behalf of felipe...@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2e1d31d123ea5f310719c6c3c51587834907b7bf
Log: - Fixed bug #62829 (stdint.h included on platform where HAVE_STDINT_H is 
not set)


[2012-08-15 16:06:58] philipm at sybase dot com

Description:

Configuring on Solaris 9 results in HAVE_STDINT_H undefined in 
main/php_config.h.  Nevertheless, there is an include error when running make.  
Surrounding the offending line with #if HAVE_STDINT_H is sufficient to resolve 
the compile error.  This started in PHP 5.4.0 and is still an issue in 5.4.5.

/bin/bash /usr/local/php/php-5.4.1/libtool --silent --preserve-dup-deps --
mode=compile cc  -Isapi/cli/ -I/usr/local/php/php-5.4.1/sapi/cli/ 
-DPHP_ATOM_INC 
-I/usr/local/php/php-5.4.1/include -I/usr/local/php/php-5.4.1/main -
I/usr/local/php/php-5.4.1 -I/usr/local/php/php-5.4.1/ext/date/lib -
I/usr/local/php/php-5.4.1/ext/ereg/regex -I/usr/local/php/php-5.4.1/TSRM -
I/usr/local/php/php-5.4.1/Zend  -D_POSIX_PTHREAD_SEMANTICS  -m64 -xmemalign=8s  
-c /usr/local/php/php-5.4.1/sapi/cli/php_http_parser.c -o 
sapi/cli/php_http_parser.lo 
"/usr/local/php/php-5.4.1/sapi/cli/php_http_parser.h", line 35: cannot find 
include file: 
cc: acomp failed for /usr/local/php/php-5.4.1/sapi/cli/php_http_parser.c
make: *** [sapi/cli/php_http_parser.lo] Error 1


Test script:
---
./configure
make

Expected result:

If HAVE_STDINT_H is not set, then stdint.h should not be included.







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