[PHP-BUG] Bug #65665 [NEW]: Exception not properly caught when opcache enabled
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.5.3 Package: opcache Bug Type: Bug Bug description:Exception not properly caught when opcache enabled Description: When running the following script with opcache enabled, the exception is not caught by the correct catch block. The exception should be caught by the 'caught by 1' block, but it is instead caught by the 'caught by 2' block. Disabling opcache causes the exception to be caught in the correct block. Run the script with: php -n -d zend_extension=opcache.so -d opcache.enable_cli=1 script.php Test script: --- ?php try { switch (1) { case 0: try { } catch (Exception $e) { } break; case 1: try { throw new Exception('aaa'); } catch (Exception $e) { echo 'caught by 1'; exit; } break; } } catch (Exception $e) { echo 'caught by 2'; exit; } Expected result: caught by 1 Actual result: -- caught by 2 -- Edit bug report at https://bugs.php.net/bug.php?id=65665edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65665r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65665r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65665r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65665r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65665r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65665r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65665r=needscript Try newer version: https://bugs.php.net/fix.php?id=65665r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65665r=support Expected behavior: https://bugs.php.net/fix.php?id=65665r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65665r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65665r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65665r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65665r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65665r=dst IIS Stability: https://bugs.php.net/fix.php?id=65665r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65665r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65665r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65665r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65665r=mysqlcfg
Bug #65255 [Com]: exception not catchable when thrown from autoload in an extended class
Edit report at https://bugs.php.net/bug.php?id=65255edit=1 ID: 65255 Comment by: ryan dot brothers at gmail dot com Reported by:ryan dot brothers at gmail dot com Summary:exception not catchable when thrown from autoload in an extended class Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Thank you for your help. Why does it matter if the class was declared literally in the try/catch block? The documentation states exceptions thrown in the __autoload function can be caught in the catch block. It works for the base class, but not extended classes. Other exceptions thrown outside of a try/catch always propagate back to the caller's try/catch such as the below. In these examples, the exception is caught, but the exception is thrown outside of the literal try/catch. ?php function __autoload($class) { throw new Exception('abcd'); } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } = ?php function test() { throw new Exception('abcd'); } try { test(); } catch (Exception $e) { echo 'caught'; exit; } = ?php class test1 { public static function go() { throw new Exception('abcd'); } } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } Previous Comments: [2013-07-14 03:17:40] larue...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php try the following example, you may found why this is expected: ?php function __autoload($class) { throw new Exception('abcd'); } try { class test1 extends test2 { public static function go() { } } test1::go(); } catch (Exception $e) { echo 'caught'; exit; } [2013-07-12 19:43:37] ryan dot brothers at gmail dot com Description: This issue may be the same issue as bug 65254 that I just submitted. The following script throws a Fatal Error rather than catching the exception. Test script: --- ?php function __autoload($class) { throw new Exception('abcd'); } class test1 extends test2 { public static function go() { } } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } Expected result: caught Actual result: -- Fatal error: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:4 Stack trace: #0 /tmp/test.php(8): __autoload('test2') #1 {main} thrown in /tmp/test.php on line 4 -- Edit this bug report at https://bugs.php.net/bug.php?id=65255edit=1
Bug #65255 [Com]: exception not catchable when thrown from autoload in an extended class
Edit report at https://bugs.php.net/bug.php?id=65255edit=1 ID: 65255 Comment by: ryan dot brothers at gmail dot com Reported by:ryan dot brothers at gmail dot com Summary:exception not catchable when thrown from autoload in an extended class Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Nevermind, I see the issue now and why it's expected behavior. The autoload gets called when the class is declared rather than when the class is first called. I'll see if your fix in bug 65254 resolves the issue I was having. Thanks again for your help. Previous Comments: [2013-07-14 13:22:01] ryan dot brothers at gmail dot com Thank you for your help. Why does it matter if the class was declared literally in the try/catch block? The documentation states exceptions thrown in the __autoload function can be caught in the catch block. It works for the base class, but not extended classes. Other exceptions thrown outside of a try/catch always propagate back to the caller's try/catch such as the below. In these examples, the exception is caught, but the exception is thrown outside of the literal try/catch. ?php function __autoload($class) { throw new Exception('abcd'); } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } = ?php function test() { throw new Exception('abcd'); } try { test(); } catch (Exception $e) { echo 'caught'; exit; } = ?php class test1 { public static function go() { throw new Exception('abcd'); } } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } [2013-07-14 03:17:40] larue...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php try the following example, you may found why this is expected: ?php function __autoload($class) { throw new Exception('abcd'); } try { class test1 extends test2 { public static function go() { } } test1::go(); } catch (Exception $e) { echo 'caught'; exit; } [2013-07-12 19:43:37] ryan dot brothers at gmail dot com Description: This issue may be the same issue as bug 65254 that I just submitted. The following script throws a Fatal Error rather than catching the exception. Test script: --- ?php function __autoload($class) { throw new Exception('abcd'); } class test1 extends test2 { public static function go() { } } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } Expected result: caught Actual result: -- Fatal error: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:4 Stack trace: #0 /tmp/test.php(8): __autoload('test2') #1 {main} thrown in /tmp/test.php on line 4 -- Edit this bug report at https://bugs.php.net/bug.php?id=65255edit=1
[PHP-BUG] Bug #65254 [NEW]: Exception not catchable when exception thrown in autoload with a namespace
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.5.0 Package: Scripting Engine problem Bug Type: Bug Bug description:Exception not catchable when exception thrown in autoload with a namespace Description: In the following code, the exception is not caught. In PHP 5.3, the exception is caught, but in PHP 5.4 and PHP 5.5, the exception is not caught. The issue only occurs when the class is in a namespace. If I remove the namespace from the class, then the exception is caught. Test script: --- ?php function __autoload($class) { require('ns_test.php'); throw new \Exception('abcd'); } try { \ns_test\test::go(); } catch (Exception $e) { echo 'caught'; exit; } = ns_test.php: ?php namespace ns_test; class test { } Expected result: caught Actual result: -- Warning: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:6 Stack trace: #0 /tmp/test.php(11): __autoload('ns_test\test') #1 {main} thrown in /tmp/test.php on line 6 Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php on line 11 -- Edit bug report at https://bugs.php.net/bug.php?id=65254edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65254r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65254r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65254r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65254r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65254r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65254r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65254r=needscript Try newer version: https://bugs.php.net/fix.php?id=65254r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65254r=support Expected behavior: https://bugs.php.net/fix.php?id=65254r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65254r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65254r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65254r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65254r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65254r=dst IIS Stability: https://bugs.php.net/fix.php?id=65254r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65254r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65254r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65254r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65254r=mysqlcfg
Bug #65254 [Com]: Exception not catchable when exception thrown in autoload with a namespace
Edit report at https://bugs.php.net/bug.php?id=65254edit=1 ID: 65254 Comment by: ryan dot brothers at gmail dot com Reported by:ryan dot brothers at gmail dot com Summary:Exception not catchable when exception thrown in autoload with a namespace Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Upon further testing, I can reproduce the issue without using namespaces with the following: ?php function __autoload($class) { require('ns_test.php'); throw new \Exception('abcd'); } try { test::go(); } catch (Exception $e) { echo 'caught'; exit; } = ns_test.php: ?php class test { } Previous Comments: [2013-07-12 18:41:12] ryan dot brothers at gmail dot com Description: In the following code, the exception is not caught. In PHP 5.3, the exception is caught, but in PHP 5.4 and PHP 5.5, the exception is not caught. The issue only occurs when the class is in a namespace. If I remove the namespace from the class, then the exception is caught. Test script: --- ?php function __autoload($class) { require('ns_test.php'); throw new \Exception('abcd'); } try { \ns_test\test::go(); } catch (Exception $e) { echo 'caught'; exit; } = ns_test.php: ?php namespace ns_test; class test { } Expected result: caught Actual result: -- Warning: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:6 Stack trace: #0 /tmp/test.php(11): __autoload('ns_test\test') #1 {main} thrown in /tmp/test.php on line 6 Fatal error: Call to undefined method ns_test\test::go() in /tmp/test.php on line 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=65254edit=1
[PHP-BUG] Bug #65255 [NEW]: exception not catchable when thrown from autoload in an extended class
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.5.0 Package: Scripting Engine problem Bug Type: Bug Bug description:exception not catchable when thrown from autoload in an extended class Description: This issue may be the same issue as bug 65254 that I just submitted. The following script throws a Fatal Error rather than catching the exception. Test script: --- ?php function __autoload($class) { throw new Exception('abcd'); } class test1 extends test2 { public static function go() { } } try { test1::go(); } catch (Exception $e) { echo 'caught'; exit; } Expected result: caught Actual result: -- Fatal error: Uncaught exception 'Exception' with message 'abcd' in /tmp/test.php:4 Stack trace: #0 /tmp/test.php(8): __autoload('test2') #1 {main} thrown in /tmp/test.php on line 4 -- Edit bug report at https://bugs.php.net/bug.php?id=65255edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65255r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65255r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65255r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65255r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65255r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65255r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65255r=needscript Try newer version: https://bugs.php.net/fix.php?id=65255r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65255r=support Expected behavior: https://bugs.php.net/fix.php?id=65255r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65255r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65255r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65255r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65255r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65255r=dst IIS Stability: https://bugs.php.net/fix.php?id=65255r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65255r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65255r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65255r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65255r=mysqlcfg
Bug #65111 [Nab]: Calling traits directly with static properties/methods
Edit report at https://bugs.php.net/bug.php?id=65111edit=1 ID: 65111 User updated by:ryan dot brothers at gmail dot com Reported by:ryan dot brothers at gmail dot com Summary:Calling traits directly with static properties/methods Status: Not a bug Type: Bug Package:Class/Object related Operating System: Linux PHP Version:5.5.0 Block user comment: N Private report: N New Comment: Thank you for the feedback. I see that the same functionality exists with abstract classes. If an abstract class has a static property or method, you can call it directly. In my particular case, I would like to enforce that all calls go to the classes that use the traits, and to prevent accidental calls to the traits directly. I will work around it in a different manner. Thanks. Previous Comments: [2013-06-25 15:15:00] fel...@php.net Thanks for explaining it. [2013-06-25 07:19:04] g...@php.net Yes, traits are not supposed to be instantiated. However, this behavior is not really related to instantiation. Traits are still a lexical entity, i.e., a programming language entity that provides a lexical scope when defined. Since PHP allows us to define functions in such scopes, we can define also static methods on traits. The way to avoid that would be to change the grammar for traits. I decided to not do that back in the day. And I still feel that it is unclear whether it would be conceptually cleaner if it is not possible to defined static state/methods. So, I would leave it as it is. Except, someone comes up with a good reason to change it. But it would also be quite a bit of a BC issue. [2013-06-25 04:30:41] larue...@php.net hmm, trait is actually a class in php, I have a quick look into this.. changing this will needs a significant works.. actually, the is_callable / do_call alreay is a little mess now. I mean the codes [2013-06-24 16:52:52] ryan dot brothers at gmail dot com Description: The documentation for traits indicates that it is not possible to instantiate a Trait on its own, but I have noticed that a trait can be called directly if it has a static property or method, as per the below example. Is this intended behavior? Or should traits be restricted from being called directly? I was under the impression that traits cannot be called directly per the documentation. If not, is there a way to prevent traits from being called directly as in the below example? Test script: --- ?php trait t1 { public static $a1 = 'test1'; public static function test() { return 'test2'; } } echo t1::$a1.\n; echo t1::test().\n; Expected result: Fatal Error that traits cannot be called directly. Actual result: -- test1 test2 -- Edit this bug report at https://bugs.php.net/bug.php?id=65111edit=1
[PHP-BUG] Bug #65111 [NEW]: Calling traits directly with static properties/methods
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.5.0 Package: Class/Object related Bug Type: Bug Bug description:Calling traits directly with static properties/methods Description: The documentation for traits indicates that it is not possible to instantiate a Trait on its own, but I have noticed that a trait can be called directly if it has a static property or method, as per the below example. Is this intended behavior? Or should traits be restricted from being called directly? I was under the impression that traits cannot be called directly per the documentation. If not, is there a way to prevent traits from being called directly as in the below example? Test script: --- ?php trait t1 { public static $a1 = 'test1'; public static function test() { return 'test2'; } } echo t1::$a1.\n; echo t1::test().\n; Expected result: Fatal Error that traits cannot be called directly. Actual result: -- test1 test2 -- Edit bug report at https://bugs.php.net/bug.php?id=65111edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65111r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65111r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65111r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65111r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65111r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65111r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65111r=needscript Try newer version: https://bugs.php.net/fix.php?id=65111r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65111r=support Expected behavior: https://bugs.php.net/fix.php?id=65111r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65111r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65111r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65111r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65111r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65111r=dst IIS Stability: https://bugs.php.net/fix.php?id=65111r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65111r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65111r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65111r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65111r=mysqlcfg
[PHP-BUG] Bug #65035 [NEW]: yield / exit segfault
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.5Git-2013-06-13 (snap) Package: Reproducible crash Bug Type: Bug Bug description:yield / exit segfault Description: The following script causes a segfault. It is occurring when exit is called in a function that is called from a generator function. Test script: --- ?php function f1() { f2(); $i = 0; yield $i; } function f2() { exit; } $rows = f1(); foreach ($rows as $row) { } Expected result: Script exits with no output. Actual result: -- [Thu Jun 13 18:44:50 2013] Script: '/tmp/test.php' --- /usr/local/src/php5.5-201306132030/Zend/zend_execute.h(196) : Block 0x7f7b17658d28 status: Beginning: Freed Start: OK End: Overflown (magic=0x005A instead of 0xEAF0B464) At least 4 bytes overflown --- -- Edit bug report at https://bugs.php.net/bug.php?id=65035edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65035r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65035r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65035r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65035r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65035r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65035r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65035r=needscript Try newer version: https://bugs.php.net/fix.php?id=65035r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65035r=support Expected behavior: https://bugs.php.net/fix.php?id=65035r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65035r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65035r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65035r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65035r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65035r=dst IIS Stability: https://bugs.php.net/fix.php?id=65035r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65035r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65035r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65035r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65035r=mysqlcfg
[PHP-BUG] Bug #61587 [NEW]: XMLReader - invalid schema error using ampersands
From: Operating system: Linux PHP version: 5.3.10 Package: XML Reader Bug Type: Bug Bug description:XMLReader - invalid schema error using ampersands Description: In the following test script, the example xml is valid against the supplied schema. DOMDocument displays no schema errors as expected, but XMLReader displays a schema violation. I was expecting XMLReader to not report any schema violations. Test script: --- ?php error_reporting(E_ALL); $xml = 'user name=a amp; b/'; $schema = '?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:element name=user xs:complexType xs:attribute name=name use=required xs:simpleType xs:restriction base=xs:string xs:enumeration value=a amp; b/ /xs:restriction /xs:simpleType /xs:attribute /xs:complexType /xs:element /xs:schema'; // create temp file with schema $schema_file = tempnam(sys_get_temp_dir(), ''); file_put_contents($schema_file, $schema); // test with DOMDocument $dom = new DOMDocument; $dom-loadXML($xml); $dom-schemaValidate($schema_file); // test with XMLReader $xmlreader = new XMLReader; $xmlreader-xml($xml); $xmlreader-setSchema($schema_file); while ($xmlreader-read() == true); $xmlreader-close(); // delete temp file unlink($schema_file); Expected result: No output Actual result: -- Warning: XMLReader::read(): Element 'user', attribute 'name': [facet 'enumeration'] The value 'a #38; b' is not an element of the set {'a b'}. in test.php on line 38 Warning: XMLReader::read(): Element 'user', attribute 'name': 'a #38; b' is not a valid value of the local atomic type. in test.php on line 38 -- Edit bug report at https://bugs.php.net/bug.php?id=61587edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61587r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61587r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61587r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61587r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61587r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61587r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61587r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61587r=needscript Try newer version: https://bugs.php.net/fix.php?id=61587r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61587r=support Expected behavior: https://bugs.php.net/fix.php?id=61587r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61587r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61587r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61587r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61587r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61587r=dst IIS Stability: https://bugs.php.net/fix.php?id=61587r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61587r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61587r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61587r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61587r=mysqlcfg
#48420 [Bgs]: stream_get_line() - invalid result when passing $length and $ending
ID: 48420 User updated by: ryan dot brothers at gmail dot com Reported By: ryan dot brothers at gmail dot com Status: Bogus Bug Type: Streams related Operating System: Linux PHP Version: 5.*, 6CVS(2009-05-29) New Comment: Thanks for your reply. Shouldn't stream_get_line() find the EOF since it will read the first 5 characters and then find the EOF when trying to read the next character since $length = 6? Also, if what you wrote is the case, I'm not sure why this: ?php $fp = tmpfile(); fwrite($fp, 12345); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); ? returns: bool(false) but this works successfully: ? $fp = tmpfile(); fwrite($fp, 12345\n67890); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); var_dump(stream_get_line($fp, 6, \n)); ? returns: string(5) 12345 string(5) 67890 On the 2nd call to stream_get_line(), there are 5 bytes remaining to be read, $length = 6, and there are no \n's remaining, which is the same exact scenario as my first example above. In my first example, stream_get_line() returns false, but in the 2nd example, stream_get_line() returns the expected string - should both of these calls have the same results? I encountered this issue when trying to use stream_get_line() to parse very large text files reading in each file in sections delimited by a string delimiter, but one of my text files did not contain this delimiter and stream_get_line() returned false for that file which I don't believe was correct. I was expecting it to read in the entire file since $length was greater than the size of the file, which is what the documentation says should occur. Thanks again for your assistance. Previous Comments: [2009-06-01 13:03:18] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Because the file is still open there is no EOF, so the stream_get_line() cannot find the line's end and there is no EOF, thus it returns false. [2009-05-29 13:09:26] ryan dot brothers at gmail dot com Thanks for your feedback. I tried it on the latest PHP 5.3 snapshot and got the same results. I noticed though when I run this: ?php fseek($fp, 0); var_dump(fgets($fp, 6)); fseek($fp, 0); var_dump(fgets($fp, 7)); ? I get the expected results of: string(5) 12345 string(5) 12345 Since the manual page for stream_get_line() states that this function is identical to fgets() except for handling of the delimiter, should stream_get_line() return the same results as fgets() for this case since my delimiter is a newline? Also, I'm not sure why these 2 calls to stream_get_line() return different output: ?php fseek($fp, 0); var_dump(stream_get_line($fp, 6)); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); ? Result: string(5) 12345 bool(false) [2009-05-29 09:00:45] lbarn...@php.net Verified. Actually this may be expected. ?php fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); ? If stream_get_line() reads only 5 bytes here there is no way to tell if this is the end of the stream (without re-reading from the stream, which would block on sockets, etc). So it can't find the end of the line and return false. The next call to stream_get_line() will mark the stream as EOF, and stream_get_line will return the line: ?php $fp = tmpfile(); fwrite($fp, '12345'); fseek($fp, 0); while (!feof($fp)) { $line = stream_get_line($fp); if ($line === false) continue; var_dump($line); } ? Result: string(5) 12345 [2009-05-29 08:39:03] lbarn...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-28 22:21:09] ryan dot brothers at gmail dot com Description: When you pass to stream_get_line() a $length that is greater than the file size and a $ending that does not appear in the file, stream_get_line() returns bool(false) rather than the string that is in your file. In the below example, when I run stream_get_line() passing in a $length of 6 and a $ending of \n, stream_get_line() returns false rather than the contents of the file. The manual states Reading ends when length bytes have been read, when the string specified by ending is found (which is not included in the return value), or on EOF (whichever comes first)., so I believe the contents of my file should be returned since EOF is first to be reached. Reproduce code: --- ?php $fp = tmpfile(); fwrite
#48420 [Fbk-Opn]: stream_get_line() - invalid result when passing $length and $ending
ID: 48420 User updated by: ryan dot brothers at gmail dot com Reported By: ryan dot brothers at gmail dot com -Status: Feedback +Status: Open Bug Type: Streams related Operating System: Linux PHP Version: 5.*, 6CVS(2009-05-29) New Comment: Thanks for your feedback. I tried it on the latest PHP 5.3 snapshot and got the same results. I noticed though when I run this: ?php fseek($fp, 0); var_dump(fgets($fp, 6)); fseek($fp, 0); var_dump(fgets($fp, 7)); ? I get the expected results of: string(5) 12345 string(5) 12345 Since the manual page for stream_get_line() states that this function is identical to fgets() except for handling of the delimiter, should stream_get_line() return the same results as fgets() for this case since my delimiter is a newline? Also, I'm not sure why these 2 calls to stream_get_line() return different output: ?php fseek($fp, 0); var_dump(stream_get_line($fp, 6)); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); ? Result: string(5) 12345 bool(false) Previous Comments: [2009-05-29 09:00:45] lbarn...@php.net Verified. Actually this may be expected. ?php fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); ? If stream_get_line() reads only 5 bytes here there is no way to tell if this is the end of the stream (without re-reading from the stream, which would block on sockets, etc). So it can't find the end of the line and return false. The next call to stream_get_line() will mark the stream as EOF, and stream_get_line will return the line: ?php $fp = tmpfile(); fwrite($fp, '12345'); fseek($fp, 0); while (!feof($fp)) { $line = stream_get_line($fp); if ($line === false) continue; var_dump($line); } ? Result: string(5) 12345 [2009-05-29 08:39:03] lbarn...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-28 22:21:09] ryan dot brothers at gmail dot com Description: When you pass to stream_get_line() a $length that is greater than the file size and a $ending that does not appear in the file, stream_get_line() returns bool(false) rather than the string that is in your file. In the below example, when I run stream_get_line() passing in a $length of 6 and a $ending of \n, stream_get_line() returns false rather than the contents of the file. The manual states Reading ends when length bytes have been read, when the string specified by ending is found (which is not included in the return value), or on EOF (whichever comes first)., so I believe the contents of my file should be returned since EOF is first to be reached. Reproduce code: --- ?php $fp = tmpfile(); fwrite($fp, '12345'); fseek($fp, 0); var_dump(stream_get_line($fp, 5)); fseek($fp, 0); var_dump(stream_get_line($fp, 6)); fseek($fp, 0); var_dump(stream_get_line($fp, 5, \n)); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); fclose($fp); Expected result: string(5) 12345 string(5) 12345 string(5) 12345 string(5) 12345 Actual result: -- string(5) 12345 string(5) 12345 string(5) 12345 bool(false) -- Edit this bug report at http://bugs.php.net/?id=48420edit=1
#48420 [NEW]: stream_get_line() - invalid result when passing $length and $ending
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Streams related Bug description: stream_get_line() - invalid result when passing $length and $ending Description: When you pass to stream_get_line() a $length that is greater than the file size and a $ending that does not appear in the file, stream_get_line() returns bool(false) rather than the string that is in your file. In the below example, when I run stream_get_line() passing in a $length of 6 and a $ending of \n, stream_get_line() returns false rather than the contents of the file. The manual states Reading ends when length bytes have been read, when the string specified by ending is found (which is not included in the return value), or on EOF (whichever comes first)., so I believe the contents of my file should be returned since EOF is first to be reached. Reproduce code: --- ?php $fp = tmpfile(); fwrite($fp, '12345'); fseek($fp, 0); var_dump(stream_get_line($fp, 5)); fseek($fp, 0); var_dump(stream_get_line($fp, 6)); fseek($fp, 0); var_dump(stream_get_line($fp, 5, \n)); fseek($fp, 0); var_dump(stream_get_line($fp, 6, \n)); fclose($fp); Expected result: string(5) 12345 string(5) 12345 string(5) 12345 string(5) 12345 Actual result: -- string(5) 12345 string(5) 12345 string(5) 12345 bool(false) -- Edit bug report at http://bugs.php.net/?id=48420edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48420r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48420r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48420r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48420r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48420r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48420r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48420r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48420r=needscript Try newer version: http://bugs.php.net/fix.php?id=48420r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48420r=support Expected behavior: http://bugs.php.net/fix.php?id=48420r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48420r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48420r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48420r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48420r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48420r=dst IIS Stability: http://bugs.php.net/fix.php?id=48420r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48420r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48420r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48420r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48420r=mysqlcfg
#48421 [NEW]: stream_get_line() - allow $length to be optional
From: ryan dot brothers at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: stream_get_line() - allow $length to be optional Description: I believe stream_get_line() should allow the $length parameter to be optional by allowing a $length of -1 that would read the remaining buffer up to either the $ending delimiter or EOF. Currently if you pass a $length of 0, the $length defaults to PHP_SOCK_CHUNK_SIZE (8192) in ext/standard/streamsfuncs.c. If you pass a length of -1, a PHP Warning is generated. Other 'similar' functions that allow length to be optional or -1 are fgets, stream_get_contents, and file_get_contents. Also, the manual page for stream_get_line() states that this function is the same fgets() except for the handling of the delimiter - but another difference, at least right now, is that the $length parameter is required in stream_get_line(), but optional in fgets(). Reproduce code: --- ?php $fp = tmpfile(); fwrite($fp, str_repeat('a', 1)); fseek($fp, 0); echo strlen(stream_get_line($fp, 0)); fseek($fp, 0); echo strlen(stream_get_line($fp, -1)); fclose($fp); Expected result: 8192 1 Actual result: -- 8192 Warning: stream_get_line(): The maximum allowed length must be greater than or equal to zero -- Edit bug report at http://bugs.php.net/?id=48421edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48421r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48421r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48421r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48421r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48421r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48421r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48421r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48421r=needscript Try newer version: http://bugs.php.net/fix.php?id=48421r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48421r=support Expected behavior: http://bugs.php.net/fix.php?id=48421r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48421r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48421r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48421r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48421r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48421r=dst IIS Stability: http://bugs.php.net/fix.php?id=48421r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48421r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48421r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48421r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48421r=mysqlcfg