[PHP-BUG] Bug #65014 [NEW]: namespaced class not found after including it in an error handler
From: alexander dot stehlik at gmail dot com Operating system: Ubuntu 12.10 / CentOS 6.4 PHP version: 5.4.16 Package: Unknown/Other Function Bug Type: Bug Bug description:namespaced class not found after including it in an error handler Description: This bug was pretty hard to track down. I uploaded a test script to make it clear. These conditions need to be met to trigger the bug: 1. You use a custom error handler 2. You use namespaces 3. You use the "use" statement 4. You require a class within the error handler 5. You have a class that uses a deprecated = & new Classname() statment Using an autoloader is no workaround because the system thinks the namespaced class is available (class_exists() returns true). Test script: --- To reproduce the bug several files are needed. I uploaded a test script. You can download it here: https://docs.google.com/file/d/0Bz4hXLAjQnaiRlJWblNuX1psdzg/edit?usp=sharing No Google account required for download! Please call index.php and you will see an error: Fatal error: Class 'namespaced_class' not found in requireerror/deprecated_reference.php on line 42 Please have a look at the code to see how it occurs. Expected result: I expect the class that is found by class_exists() and included with a "use" statement is accessible. Actual result: -- I get an error: Fatal error: Class 'namespaced_class' not found in deprecated_reference.php on line 31 -- Edit bug report at https://bugs.php.net/bug.php?id=65014&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65014&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65014&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65014&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65014&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65014&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65014&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65014&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65014&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65014&r=support Expected behavior: https://bugs.php.net/fix.php?id=65014&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65014&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65014&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65014&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65014&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65014&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65014&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65014&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65014&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65014&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65014&r=mysqlcfg
[PHP-BUG] Bug #64912 [NEW]: Unexpected output when parsing PHP files containing NUL characters
From: alexander dot stehlik at gmail dot com Operating system: Linux (Ubuntu and CentOS) PHP version: 5.4.15 Package: mbstring related Bug Type: Bug Bug description:Unexpected output when parsing PHP files containing NUL characters Description: When this setting is used: zend.multibyte = On and I parse a PHP file that contains a NUL character (this one here: http://en.wikipedia.org/wiki/Null_character) I get some weird output. When I do not use the mbstring.internal_encoding setting I get a lot of question marks (?). When I use mbstring.internal_encoding = utf-8 I get some characters that look like Chinese to me. Test script: --- > test.php $var = 'here is null'; ?> Expected result: When I run the given example with php test.php I expect no output, even when this setting is active: zend.multibyte = On Actual result: -- With the setting zend.multibyte = On I get some weird output (depending on the configured internal encoding): With the setting mbstring.internal_encoding = utf-8 I get an output that looks like this: ã°¿ç¨çâ¶æ ²â½â§æ¡¥ç©â³æ¤ 湵汬â»à¨¿ã¸ Without the setting the output looks like this: ??? ? -- Edit bug report at https://bugs.php.net/bug.php?id=64912&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64912&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64912&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64912&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64912&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64912&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64912&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64912&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64912&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64912&r=support Expected behavior: https://bugs.php.net/fix.php?id=64912&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64912&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64912&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64912&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64912&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64912&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64912&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64912&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64912&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64912&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64912&r=mysqlcfg
Bug #62351 [Com]: UTF-8 chars fail to be printed out properly with zend.multibyte
Edit report at https://bugs.php.net/bug.php?id=62351&edit=1 ID: 62351 Comment by: alexander dot stehlik at gmail dot com Reported by:php at sebastianmendel dot de Summary:UTF-8 chars fail to be printed out properly with zend.multibyte Status: Open Type: Bug Package:Unicode Engine related Operating System: GNU/Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I'm not sure if this issue is related but here is the problem I have with declare(ENCODING = 'utf-8'): Tested PHP Versions: PHP 5.4.6-1ubuntu1.1 (cli) PHP 5.4.6-1ubuntu1.1 (cgi-fcgi) Put this in a file (test.php): Run php test.php > test.txt In text.txt you can find some unreadable characters. This always occurs if there are special chars in any COMMENTS in the PHP file. Previous Comments: [2012-12-05 09:46:06] bukin242 at yandex dot ru Please fix in the new versions of php [2012-06-18 15:18:20] php at sebastianmendel dot de Description: Enabling zend.multibyte and having declare(encoding = UTF-8) in UTF-8 encoded scripts does not print UTF-8 chars properly. Same script (still encoded as UTF-8) but with declare(encoding = ISO-8859-1) prints out UTF-8 chars correct. >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep multi zend.multibyte => On => On >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep UTF default_charset => UTF-8 => UTF-8 zend.script_encoding => UTF-8 => UTF-8 exif.encode_unicode => UTF-8 => UTF-8 iconv.input_encoding => UTF-8 => UTF-8 iconv.internal_encoding => UTF-8 => UTF-8 iconv.output_encoding => UTF-8 => UTF-8 LANG => de_DE.UTF-8 _SERVER["LANG"] => de_DE.UTF-8 Test script: --- Expected result: "aäaà "aäaà Actual result: -- "aa "aâaâ -- Edit this bug report at https://bugs.php.net/bug.php?id=62351&edit=1