[PHP-BUG] Bug #65014 [NEW]: namespaced class not found after including it in an error handler

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

[PHP-BUG] Bug #64912 [NEW]: Unexpected output when parsing PHP files containing NUL characters

2013-05-23 Thread alexander dot stehlik at gmail dot com 
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:
---
?php

// I can not insert the NUL character here.
// To put it in a PHP file you can use the console:
//
// echo -e here is \0 null  test.php

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

Bug #62351 [Com]: UTF-8 chars fail to be printed out properly with zend.multibyte

2013-02-11 Thread alexander dot stehlik at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=62351edit=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):

?php
declare(ENCODING = 'utf-8') ;

//ä ü ö

?

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:
---
?php
declare(encoding = 'UTF-8');
echo htmlspecialchars('aäaß', ENT_QUOTES | ENT_IGNORE, 'UTF-8');
echo \n . 'aäaß';
?




Expected result:

quot;aäaß
aäaß

Actual result:
--
quot;aa
a▒a▒






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