Req #45351 [Com]: Exception::getTrace() should return 'object' array-element
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()
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服务器崩溃.
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服务器崩溃.
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
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服务器崩溃.
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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