Bug #64504 [Opn]: Forward reference of a class with interface

2013-03-24 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=64504&edit=1

 ID: 64504
 Updated by: larue...@php.net
 Reported by:rstoll at tutteli dot ch
 Summary:Forward reference of a class with interface
 Status: Open
 Type:   Bug
 Package:Class/Object related
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

always declare before use(or use autoload mechanism)...

this is the current implementation, I don't think it's need to be fixed.


Previous Comments:

[2013-03-24 15:56:15] rstoll at tutteli dot ch

Description:

My PHP version is 5.4.7

forward references of classes do not work if the class implements an interface.

Test script:
---
$a = new Ok(); //that's ok

class OK{}

$a = new Fail(); //fails


interface I{}
class Fail implements I{}


Expected result:

I would expect that forward references are also supported for classes which 
implement an interface







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

Bug #64508 [Opn]: conversions.c: undefined reference to php_set_inet6_addr

2013-03-24 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=64508&edit=1

 ID: 64508
 Updated by: larue...@php.net
 Reported by:peacech at gmail dot com
 Summary:conversions.c: undefined reference to
 php_set_inet6_addr
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux
 PHP Version:5.5.0beta1
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

confirm


Previous Comments:

[2013-03-25 06:07:44] peacech at gmail dot com

Description:

Compiling PHP with --disable-ipv6 gives above error.







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

[PHP-BUG] Bug #64508 [NEW]: conversions.c: undefined reference to php_set_inet6_addr

2013-03-24 Thread peacech at gmail dot com 
From: peacech at gmail dot com
Operating system: Linux
PHP version:  5.5.0beta1
Package:  Compile Failure
Bug Type: Bug
Bug description:conversions.c: undefined reference to php_set_inet6_addr

Description:

Compiling PHP with --disable-ipv6 gives above error.


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

Bug #64503 [PATCH]: Compilation fails with error: conflicting types for 'zendparse'

2013-03-24 Thread larue...@php.net 
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1

 ID: 64503
 Patch added by: larue...@php.net
 Reported by:stormbyte at gmail dot com
 Summary:Compilation fails with error: conflicting types for
 'zendparse'
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Gentoo
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bison_build_2.patch
Revision:   1364190380
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build_2.patch&revision=1364190380


Previous Comments:

[2013-03-25 05:16:46] larue...@php.net

The following patch has been added/updated:

Patch Name: bison_build.patch
Revision:   1364188606
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build.patch&revision=1364188606


[2013-03-24 15:40:54] stormbyte at gmail dot com

Description:

These are the last lines for compile log output:

/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer_data.c:26:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20503] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer_data.c on localhost failed
make: *** [ext/tokenizer/tokenizer_data.lo] Error 1
make: *** Waiting for unfinished jobs
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:33:0:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:25:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed
make: *** [ext/tokenizer/tokenizer.lo] Error 1

Test script:
---
In my case, just emerge php OR try to compile it

Expected result:

Compilation successful

Actual result:
--
Compile error






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

Bug #64503 [PATCH]: Compilation fails with error: conflicting types for 'zendparse'

2013-03-24 Thread larue...@php.net 
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1

 ID: 64503
 Patch added by: larue...@php.net
 Reported by:stormbyte at gmail dot com
 Summary:Compilation fails with error: conflicting types for
 'zendparse'
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Gentoo
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bison_build.patch
Revision:   1364188606
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build.patch&revision=1364188606


Previous Comments:

[2013-03-24 15:40:54] stormbyte at gmail dot com

Description:

These are the last lines for compile log output:

/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer_data.c:26:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20503] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer_data.c on localhost failed
make: *** [ext/tokenizer/tokenizer_data.lo] Error 1
make: *** Waiting for unfinished jobs
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:33:0:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:25:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed
make: *** [ext/tokenizer/tokenizer.lo] Error 1

Test script:
---
In my case, just emerge php OR try to compile it

Expected result:

Compilation successful

Actual result:
--
Compile error






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

Bug #64505 [Dup]: Compile error with Mysqln

2013-03-24 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=64505&edit=1

 ID: 64505
 Updated by: larue...@php.net
 Reported by:chefuri at gmail dot com
 Summary:Compile error with Mysqln
 Status: Duplicate
 Type:   Bug
 Package:Compile Failure
 Operating System:   CENTOS x86_64
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

dup to #64503


Previous Comments:

[2013-03-25 03:42:32] larue...@php.net

dup to #64503


[2013-03-24 16:07:47] chefuri at gmail dot com

Description:

I can't compile the PHP 5.5.0 beta1 with this options:

'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd' '--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd' '--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib' '--with-
gd=shared'

This configuration works correctly with alpha versions.

Thanks!
NOTE: With PHP 5.5.0alpha6 i obtained this error : https://bugs.php.net/bug.php?
id=64373


Test script:
---


'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd' '--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd' '--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib' '--with-
gd=shared'

./make

ext/mysqlnd/.libs/mysqlnd_ps.o: In function `mysqlnd_stmt_fetch_row_buffered':
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_unlock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_unlock'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

-

php-5.5.0alpha6/meta_ccld  -Iext/standard/ 
-I/root/desc/php-5.5.0alpha6/ext/standard/ -DPHP_ATOM_INC 
-I/root/desc/php-5.5.0alpha6/include -I/root/desc/php-5.5.0alpha6/main 
-I/root/desc/php-5.5.0alpha6 -I/root/desc/php-5.5.0alpha6/ext/date/lib 
-I/root/desc/php-5.5.0alpha6/ext/ereg/regex -I/usr/include/libxml2 
-I/root/desc/php-5.5.0alpha6/ext/sqlite3/libsqlite 
-I/root/desc/php-5.5.0alpha6/TSRM -I/root/desc/php-5.5.0alpha6/Zend  
-D_REENTRANT  -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS  -c 
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c -o 
ext/standard/basic_functions.lo 
In file included from 
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c:48:
/root/desc/php-5.5.0alpha6/Zend/zend_language_parser.h:331: error: conflicting 
types for 'zendparse'
/root/desc/php-5.5.0alpha6/Zend/zend_globals_macros.h:35: note: previous 
declaration of 'zendparse' was here
make: *** [ext/standard/basic_functions.lo] Error 1







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

Bug #64505 [Opn->Dup]: Compile error with Mysqln

2013-03-24 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=64505&edit=1

 ID: 64505
 Updated by: larue...@php.net
 Reported by:chefuri at gmail dot com
 Summary:Compile error with Mysqln
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:Compile Failure
 Operating System:   CENTOS x86_64
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

dup to #64503


Previous Comments:

[2013-03-24 16:07:47] chefuri at gmail dot com

Description:

I can't compile the PHP 5.5.0 beta1 with this options:

'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd' '--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd' '--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib' '--with-
gd=shared'

This configuration works correctly with alpha versions.

Thanks!
NOTE: With PHP 5.5.0alpha6 i obtained this error : https://bugs.php.net/bug.php?
id=64373


Test script:
---


'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd' '--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd' '--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib' '--with-
gd=shared'

./make

ext/mysqlnd/.libs/mysqlnd_ps.o: In function `mysqlnd_stmt_fetch_row_buffered':
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_unlock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference to 
`tsrm_mutex_unlock'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

-

php-5.5.0alpha6/meta_ccld  -Iext/standard/ 
-I/root/desc/php-5.5.0alpha6/ext/standard/ -DPHP_ATOM_INC 
-I/root/desc/php-5.5.0alpha6/include -I/root/desc/php-5.5.0alpha6/main 
-I/root/desc/php-5.5.0alpha6 -I/root/desc/php-5.5.0alpha6/ext/date/lib 
-I/root/desc/php-5.5.0alpha6/ext/ereg/regex -I/usr/include/libxml2 
-I/root/desc/php-5.5.0alpha6/ext/sqlite3/libsqlite 
-I/root/desc/php-5.5.0alpha6/TSRM -I/root/desc/php-5.5.0alpha6/Zend  
-D_REENTRANT  -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS  -c 
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c -o 
ext/standard/basic_functions.lo 
In file included from 
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c:48:
/root/desc/php-5.5.0alpha6/Zend/zend_language_parser.h:331: error: conflicting 
types for 'zendparse'
/root/desc/php-5.5.0alpha6/Zend/zend_globals_macros.h:35: note: previous 
declaration of 'zendparse' was here
make: *** [ext/standard/basic_functions.lo] Error 1







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

Bug #63914 [Opn]: zend_do_fcall_common_helper_SPEC does not handle exceptions properly

2013-03-24 Thread stas 
Edit report at https://bugs.php.net/bug.php?id=63914&edit=1

 ID: 63914
 Updated by: s...@php.net
 Reported by:whatthejeff at gmail dot com
 Summary:zend_do_fcall_common_helper_SPEC does not handle
 exceptions properly
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   All
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Dmitry, could you review the proposed patch?


Previous Comments:

[2013-01-06 01:27:33] whatthejeff at gmail dot com

Pull request added: https://github.com/php/php-src/pull/250


[2013-01-06 00:35:00] whatthejeff at gmail dot com

Description:

The `zend_verify_arg_type` check in `zend_do_fcall_common_helper_SPEC` can 
generate unhanded exceptions when a user-defined error handler is set. This can 
lead to the following unexpected behaviors:

 * xdebug (and similar extensions using `execute_internal`) with PHP <= 5.4 
will 
segfault (http://bugs.xdebug.org/view.php?id=897)
 * xdebug (and similar extensions using `execute_internal`) with PHP 5.5+ will 
continue to execute the internal function in an inconsistant state.
 * PHP without xdebug-like extensions will continue to execute the internal 
function, even though it's unnecessary.

---

NOTE: I will send a pull request on github shortly.

Test script:
---
saveXML('foo');

Expected result:

Fatal error: Uncaught exception 'Exception' in 
/home/whatthejeff/php2/segfault.php:6
Stack trace:
#0 [internal function]: PHPUnit_Util_ErrorHandler::handleError(4096, 'Argument 
1 
pass...', '/home/whattheje...', 16, Array)
#1 /home/whatthejeff/php2/segfault.php(16): DOMDocument->saveXML('foo')
#2 {main}
  thrown in /home/whatthejeff/php2/segfault.php on line 6

Actual result:
--
GDB session with PHP 5.4 / xdebug (edited for brevity):
---

[whatthejeff@xdebug php2]$ gdb php

...

(gdb) break zend_vm_execute.h:628
Breakpoint 1 at 0x870e1d: file /home/whatthejeff/php2/Zend/zend_vm_execute.h, 
line 
628.
(gdb) break zend_vm_execute.h:639
Breakpoint 2 at 0x870eb8: file /home/whatthejeff/php2/Zend/zend_vm_execute.h, 
line 
639.
(gdb) run segfault.php
Starting program: /usr/local/bin/php segfault.php

...

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.80.el6_3.6.x86_64 
nss-softokn-freebl-3.12.9-11.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) c
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac310, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac310, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) step
644 zend_execute_internal(execute_data, 
RETURN_VALUE_USED(opline) TSRMLS_CC);
(gdb) 
xdebug_execute_internal (current_execute_data=0x77fac0f8, 
return_value_used=0, 
tsrm_ls=0xff0090) at /home/whatthejeff/xdebug/xdebug.c:1506

...

(gdb) 
1547execute_internal(current_execute_data, 
return_value_used 
TSRMLS_CC);
(gdb) step
execute_internal (execute_data_ptr=0x77fac0f8, return_value_used=0, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_execute.

Bug #64506 [Dup]: PHP can not read or write file correctly if file name have special char like š

2013-03-24 Thread vibbow at hotmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64506&edit=1

 ID: 64506
 User updated by:vibbow at hotmail dot com
 Reported by:vibbow at hotmail dot com
 Summary:PHP can not read or write file correctly if file
 name have special char like Å¡
 Status: Duplicate
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows 7
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

For the second part.

I had try convert the file name to UTF-8, GBK or GB2312 encode,
but none of these encode will save the file in correct file name

For the third part.

I had try convert the filename to all encode which mb_convert support,
But none of any encode will work.


Previous Comments:

[2013-03-25 02:16:58] paj...@php.net

duplicate of bugs about unicode API support for file operations.

Temporary solution is to either choose the right encoding (windows encoding), 
mbstring supports conversions for all windows encoding.


[2013-03-25 02:07:50] vibbow at hotmail dot com

Description:

System envirement:
Windows 8 x64 Simplified Chinese
PHP 5.4.13 nts (Non debug version, download from windows.php.net)

1. This problem only happened on Windows (I tried on linux, it works fine)

2. If I want to save a file with special character in file name (For example, I 
want to save file to "š.txt"), the file name will actually become "拧.txt"

3. If in my folder, I have a file named Å¡.txt, when I use scandir to list all 
the files in thsi folder, this file will list as "?.txt"

Test script:
---








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

Bug #64506 [Opn->Dup]: PHP can not read or write file correctly if file name have special char like š

2013-03-24 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=64506&edit=1

 ID: 64506
 Updated by: paj...@php.net
 Reported by:vibbow at hotmail dot com
 Summary:PHP can not read or write file correctly if file
 name have special char like Å¡
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows 7
 PHP Version:5.4.13
 Block user comment: N
 Private report: N



Previous Comments:

[2013-03-25 02:16:58] paj...@php.net

duplicate of bugs about unicode API support for file operations.

Temporary solution is to either choose the right encoding (windows encoding), 
mbstring supports conversions for all windows encoding.


[2013-03-25 02:07:50] vibbow at hotmail dot com

Description:

System envirement:
Windows 8 x64 Simplified Chinese
PHP 5.4.13 nts (Non debug version, download from windows.php.net)

1. This problem only happened on Windows (I tried on linux, it works fine)

2. If I want to save a file with special character in file name (For example, I 
want to save file to "š.txt"), the file name will actually become "拧.txt"

3. If in my folder, I have a file named Å¡.txt, when I use scandir to list all 
the files in thsi folder, this file will list as "?.txt"

Test script:
---








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

Bug #64506 [Opn]: PHP can not read or write file correctly if file name have special char like š

2013-03-24 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=64506&edit=1

 ID: 64506
 Updated by: paj...@php.net
 Reported by:vibbow at hotmail dot com
 Summary:PHP can not read or write file correctly if file
 name have special char like Å¡
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows 7
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

duplicate of bugs about unicode API support for file operations.

Temporary solution is to either choose the right encoding (windows encoding), 
mbstring supports conversions for all windows encoding.


Previous Comments:

[2013-03-25 02:07:50] vibbow at hotmail dot com

Description:

System envirement:
Windows 8 x64 Simplified Chinese
PHP 5.4.13 nts (Non debug version, download from windows.php.net)

1. This problem only happened on Windows (I tried on linux, it works fine)

2. If I want to save a file with special character in file name (For example, I 
want to save file to "š.txt"), the file name will actually become "拧.txt"

3. If in my folder, I have a file named Å¡.txt, when I use scandir to list all 
the files in thsi folder, this file will list as "?.txt"

Test script:
---








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

Bug #64490 [Opn->Csd]: struct flock undefined on FreeBSD

2013-03-24 Thread stas 
Edit report at https://bugs.php.net/bug.php?id=64490&edit=1

 ID: 64490
 Updated by: s...@php.net
 Reported by:ond...@php.net
 Summary:struct flock undefined on FreeBSD
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   GNU kFreeBSD
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=c342c9b96452c5660c32a6c1a34d9dab9066afef
Log: fix bug #64490 - add __FreeBSD_kernel__ to allowed FreeBSD defs


Previous Comments:

[2013-03-22 18:06:15] krak...@php.net

The following patch has been added/updated:

Patch Name: kfbsd.preprocessor
Revision:   1363975574
URL:
https://bugs.php.net/patch-display.php?bug=64490&patch=kfbsd.preprocessor&revision=1363975574


[2013-03-22 12:32:47] ond...@php.net

Description:

Zend OpCache doesn't build on Debian GNU/kFreeBSD (amd64).

Full build log: 
https://buildd.debian.org/status/fetch.php?pkg=php5&arch=kfreebsd-
amd64&ver=5.5.0~beta1-1&stamp=1363952343


Expected result:

PHP built

Actual result:
--
/bin/bash /build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/libtool --preserve-dup-deps --mode=compile x86_64-
kfreebsd-gnu-gcc  -Iext/opcache/ -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/ -DPHP_ATOM_INC -I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/include -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1 -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/ereg/regex -I/usr/include/libxml2 -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/mbstring/libmbfl -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl -I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/mbstring/libmbfl/mbfl -I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl/mbfl -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/cli-build/-I/usr/include -O2 -Wall -fsigned-char -
fno-strict-aliasing -gstabs -fvisibility=hidden  -prefer-pic -c /build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/opcache/ZendAccelerator.c -o ext/opcache/ZendAccelerator.lo 
libtool: compile:  x86_64-kfreebsd-gnu-gcc -Iext/opcache/ "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/" -
DPHP_ATOM_INC "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/include" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/main" "-I/build/buildd-php5_5.5.0~beta1-
1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1" "-I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/date/lib" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib" "-
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/ereg/regex" -I/usr/include/libxml2 "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl" 
"-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/ext/mbstring/libmbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl/mbfl" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/ext/mbstring/libmbfl/mbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/TSRM" "-I/build/buildd-php5_5.5.0~beta1-
1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/Zend" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/main" "-
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/Zend" 
"-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/TSRM"
 
"-I

[PHP-BUG] Bug #64506 [NEW]: PHP can not read or write file correctly if file name have special char like š

2013-03-24 Thread vibbow at hotmail dot com 
From: vibbow at hotmail dot com
Operating system: Windows 7
PHP version:  5.4.13
Package:  Filesystem function related
Bug Type: Bug
Bug description:PHP can not read or write file correctly if file name have 
special char like Å¡

Description:

System envirement:
Windows 8 x64 Simplified Chinese
PHP 5.4.13 nts (Non debug version, download from windows.php.net)

1. This problem only happened on Windows (I tried on linux, it works fine)

2. If I want to save a file with special character in file name (For
example, I want to save file to "Å¡.txt"), the file name will actually
become "拧.txt"

3. If in my folder, I have a file named Å¡.txt, when I use scandir to list
all the files in thsi folder, this file will list as "?.txt"

Test script:
---



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

Bug #64499 [Csd->Nab]: test on php version = 5.3.13 and 5.3.5

2013-03-24 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=64499&edit=1

 ID: 64499
 Updated by: paj...@php.net
 Reported by:dhaliwaljee at gmail dot com
 Summary:test on php version = 5.3.13 and 5.3.5
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:GD related
 Operating System:   all
 PHP Version:5.3.23
 Block user comment: N
 Private report: N



Previous Comments:

[2013-03-24 16:24:47] dhaliwaljee at gmail dot com

Thanks to pajoye,
it solved my problem.

This site is very helpful rather than any other.


[2013-03-24 14:53:54] paj...@php.net

Or be sure that no space or other empty characters (or non empty :) are sent 
before the image, like a new line/space before the opening http://localhost/Test/index.php"; cannot be displayed because it 
contains errors.






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

Bug #64499 [Fbk->Csd]: test on php version = 5.3.13 and 5.3.5

2013-03-24 Thread dhaliwaljee at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64499&edit=1

 ID: 64499
 User updated by:dhaliwaljee at gmail dot com
 Reported by:dhaliwaljee at gmail dot com
 Summary:test on php version = 5.3.13 and 5.3.5
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:GD related
 Operating System:   all
 PHP Version:5.3.23
 Block user comment: N
 Private report: N

 New Comment:

Thanks to pajoye,
it solved my problem.

This site is very helpful rather than any other.


Previous Comments:

[2013-03-24 14:53:54] paj...@php.net

Or be sure that no space or other empty characters (or non empty :) are sent 
before the image, like a new line/space before the opening http://localhost/Test/index.php"; cannot be displayed because it 
contains errors.






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

Req #64502 [Ana]: BIG Request: files or memcached based storage (please read before dismissing)

2013-03-24 Thread normadize at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64502&edit=1

 ID: 64502
 User updated by:normadize at gmail dot com
 Reported by:normadize at gmail dot com
 Summary:BIG Request: files or memcached based storage
 (please read before dismissing)
 Status: Analyzed
 Type:   Feature/Change Request
 Package:opcache
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

"You posted this in two places, so I will add my answer here as well:"

I didn't know which has more visibility. Apologies if this is a hassle. I'll 
reply here too, once again, but do let me know which one I should stick to if 
required.


"this would be exactly the same if you had a file-based storage mechanism"

Indeed, and I mentioned that as well. However, the OS would cache those files 
after the first hit, so after that point you should see great benefits as 
you're effectively reading from RAM ... granted, until that portion of OS file 
cache is overridden.

So on average, this should have visible advantages.

If however you always read from disk, i.e. OS does not cache the files, then 
yes, the advantages are not great, but it's unlikely for the OS not to cache 
them and get at least a few OS file-cache hits (i.e. RAM) before they get 
wiped, especially on busy websites.

p.s. I no longer have the evidence, but I did mention I saw big improvements a 
long time ago when eAccelerator also had a file-based storage engine.


Previous Comments:

[2013-03-24 15:20:18] ras...@php.net

You posted this in two places, so I will add my answer here as well:

You are making a lot of assumptions here based on no evidence. The way opcode 
caches work, it's not like it creates a single op_array of an entire 
application 
and writes that. Each included file is turned into an op_array, so when you say 
an app has to load hundreds of files, this would be exactly the same if you had 
a file-based storage mechanism. The OS file cache would work exactly the same 
for php script files vs. op_array files, so no difference there. When I 
actually 
tested this with APC I saw less than a 5% speedup reading op_arrays from disk 
vs. simply re-compiling from the script. This is likely because we actually 
have 
to read more stuff in the compiled op_array case since it isn't just op_arrays 
stored. We also store function and object lists alongside so the savings you 
get 
from not having to recompile is eaten by the extra disk reads you need.

And yes, a memcache backend would suffer from the same fate assuming it is a 
standard distributed memcache setup. A local memcache instance with no network 
traffic might work, but I can't see that being available to many SuPHP users.


[2013-03-24 15:00:51] normadize at gmail dot com

Description:

Now that Zend Optimizer Plus will make it to 5.5, I think it's time to 
resurface this discussion. PLEASE do read it before dismissing it.

Time changed. There are a lot of SuPHP (and the likes) installations out there 
that suffer from horrible performance ... and as we know, all current opcode 
cachers fail. SuPHP and the likes now account for quite a lot of php 
installations, a really non-negligible number.

All those installations would greatly benefit from a storage engine that 
survives between requests. Both users and hosting providers would be extremely 
grateful!

There are so many slow and badly written but still very popular scripts out 
there cough like WordPress cough, especially when they have all sort of other 
popular and slow plugins being executed as part of a single request. This tends 
to be the norm now with websites based on WordPress, Drupal, etc ... and a ton 
of them are hosted in SuPHP setups.

I know the cons of file-based storage but let's reconsider it for a moment.

MEMCACHED.

would be a nice solution but most probably (especially for SuPHP environments), 
hosting providers won't allow it or won't provide it at all since it would be a 
memory hog as clients fill up the server's RAM with cached php opcode.

It would still be great to have as a storage engine though.

FILE-BASED.

Everybody says cache hits would be slow. And yes, they would slower than SHM. 
However:

it would still be considerably faster than loading and executing an entire 
chain of scripts long scripts, e.g. WordPress + tons of plugins (all those php 
files have to be read anyway without an opcode cacher)

The OS would cache the opcode files transparently in its file cache -- and 
hosting providers will not disable that as they don't want their disks thrashed 
-- so this would actually be pretty much as fast as SHM-based solutions as long 
as the files are in the OS's file cache. On average, it would still be 
considerably faster than withou

[PHP-BUG] Bug #64505 [NEW]: Compile error with Mysqln

2013-03-24 Thread chefuri at gmail dot com 
From: chefuri at gmail dot com
Operating system: CENTOS x86_64
PHP version:  5.5.0beta1
Package:  Compile Failure
Bug Type: Bug
Bug description:Compile error with Mysqln

Description:

I can't compile the PHP 5.5.0 beta1 with this options:

'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd'
'--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd'
'--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib'
'--with-
gd=shared'

This configuration works correctly with alpha versions.

Thanks!
NOTE: With PHP 5.5.0alpha6 i obtained this error :
https://bugs.php.net/bug.php?
id=64373


Test script:
---


'./configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--enable-mysqlnd'
'--
enable-inline-optimization' '--disable-debug' '--with-mysql=mysqlnd'
'--with-
pdo-mysql=shared' '--enable-mysqlnd-compression-support' '--with-zlib'
'--with-
gd=shared'

./make

ext/mysqlnd/.libs/mysqlnd_ps.o: In function
`mysqlnd_stmt_fetch_row_buffered':
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference
to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference
to 
`tsrm_mutex_unlock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference
to 
`tsrm_mutex_lock'
/root/desc/php-5.5.0beta1/ext/mysqlnd/mysqlnd_ps.c:794: undefined reference
to 
`tsrm_mutex_unlock'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

-

php-5.5.0alpha6/meta_ccld  -Iext/standard/
-I/root/desc/php-5.5.0alpha6/ext/standard/ -DPHP_ATOM_INC
-I/root/desc/php-5.5.0alpha6/include -I/root/desc/php-5.5.0alpha6/main
-I/root/desc/php-5.5.0alpha6 -I/root/desc/php-5.5.0alpha6/ext/date/lib
-I/root/desc/php-5.5.0alpha6/ext/ereg/regex -I/usr/include/libxml2
-I/root/desc/php-5.5.0alpha6/ext/sqlite3/libsqlite
-I/root/desc/php-5.5.0alpha6/TSRM -I/root/desc/php-5.5.0alpha6/Zend 
-D_REENTRANT  -I/usr/include -g -O2 -fvisibility=hidden -pthread -DZTS  -c
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c -o
ext/standard/basic_functions.lo 
In file included from
/root/desc/php-5.5.0alpha6/ext/standard/basic_functions.c:48:
/root/desc/php-5.5.0alpha6/Zend/zend_language_parser.h:331: error:
conflicting types for 'zendparse'
/root/desc/php-5.5.0alpha6/Zend/zend_globals_macros.h:35: note: previous
declaration of 'zendparse' was here
make: *** [ext/standard/basic_functions.lo] Error 1


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

[PHP-BUG] Bug #64504 [NEW]: Forward reference of a class with interface

2013-03-24 Thread rstoll at tutteli dot ch 
From: rstoll at tutteli dot ch
Operating system: 
PHP version:  5.4.13
Package:  Class/Object related
Bug Type: Bug
Bug description:Forward reference of a class with interface

Description:

My PHP version is 5.4.7

forward references of classes do not work if the class implements an
interface.

Test script:
---
$a = new Ok(); //that's ok

class OK{}

$a = new Fail(); //fails


interface I{}
class Fail implements I{}


Expected result:

I would expect that forward references are also supported for classes which
implement an interface


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

[PHP-BUG] Bug #64503 [NEW]: Compilation fails with error: conflicting types for 'zendparse'

2013-03-24 Thread stormbyte at gmail dot com 
From: stormbyte at gmail dot com
Operating system: Gentoo
PHP version:  5.5.0beta1
Package:  Compile Failure
Bug Type: Bug
Bug description:Compilation fails with error: conflicting types for 'zendparse'

Description:

These are the last lines for compile log output:

/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer_data.c:26:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20503] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer_data.c on localhost failed
make: *** [ext/tokenizer/tokenizer_data.lo] Error 1
make: *** Waiting for unfinished jobs
In file included from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:33:0:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for 
'zendparse'
In file included from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
 from
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:25:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of 
'zendparse' was here
distcc[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed
make: *** [ext/tokenizer/tokenizer.lo] Error 1

Test script:
---
In my case, just emerge php OR try to compile it

Expected result:

Compilation successful

Actual result:
--
Compile error

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

Bug #62820 [Com]: mysqlnd API incompatability breaks PDOStatement->nextRowset()

2013-03-24 Thread ni...@php.net 
Edit report at https://bugs.php.net/bug.php?id=62820&edit=1

 ID: 62820
 Comment by: ni...@php.net
 Reported by:ni...@php.net
 Summary:mysqlnd API incompatability breaks
 PDOStatement->nextRowset()
 Status: Assigned
 Type:   Bug
 Package:PDO related
 PHP Version:master-Git-2012-08-14 (Git)
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Just looked at the code again, what I said above is wrong. The code checks 
mysql_more_results() before 
(http://lxr.php.net/xref/PHP_TRUNK/ext/pdo_mysql/mysql_statement.c#414), so it 
should not be related to the return value of mysql_next_result(). Something 
else is wrong.


Previous Comments:

[2012-08-14 18:29:18] ni...@php.net

Related bug report: https://bugs.php.net/bug.php?id=62803


[2012-08-14 18:28:31] ni...@php.net

Description:

When the mysqlnd driver is used PDOStatement->nextRowset() does not return 
bool(false) when there are no more result sets. This causes several test 
failures, which all have a diff looking similar to this:

008+
009+ Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error in 
%s/bug_41997.php on line 11
010+ array(0) {
011+ }

This can be traced down to mysql_next_result() returning 0 instead of -1 in 
http://lxr.php.net/xref/PHP_TRUNK/ext/pdo_mysql/mysql_statement.c#415.

The reason is that (when using mysqlnd) mysql_next_result is aliased to 
mysqlnd_next_result, but both have different APIs: The mysqlnd_ version only 
returns PASS = 0 or FAIL = 1, whereas the mysql_ version returns -1 if the call 
worked, but there were no more resultsets.

This is documented at 
http://dev.mysql.com/doc/refman/5.0/en/mysql-next-result.html in the "Return 
Values" section. The default mysqlnd next_result implementation is here: 
http://lxr.php.net/xref/PHP_TRUNK/ext/mysqlnd/mysqlnd.c#2100.







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

Req #64502 [Opn->Ana]: BIG Request: files or memcached based storage (please read before dismissing)

2013-03-24 Thread rasmus 
Edit report at https://bugs.php.net/bug.php?id=64502&edit=1

 ID: 64502
 Updated by: ras...@php.net
 Reported by:normadize at gmail dot com
 Summary:BIG Request: files or memcached based storage
 (please read before dismissing)
-Status: Open
+Status: Analyzed
 Type:   Feature/Change Request
 Package:opcache
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

You posted this in two places, so I will add my answer here as well:

You are making a lot of assumptions here based on no evidence. The way opcode 
caches work, it's not like it creates a single op_array of an entire 
application 
and writes that. Each included file is turned into an op_array, so when you say 
an app has to load hundreds of files, this would be exactly the same if you had 
a file-based storage mechanism. The OS file cache would work exactly the same 
for php script files vs. op_array files, so no difference there. When I 
actually 
tested this with APC I saw less than a 5% speedup reading op_arrays from disk 
vs. simply re-compiling from the script. This is likely because we actually 
have 
to read more stuff in the compiled op_array case since it isn't just op_arrays 
stored. We also store function and object lists alongside so the savings you 
get 
from not having to recompile is eaten by the extra disk reads you need.

And yes, a memcache backend would suffer from the same fate assuming it is a 
standard distributed memcache setup. A local memcache instance with no network 
traffic might work, but I can't see that being available to many SuPHP users.


Previous Comments:

[2013-03-24 15:00:51] normadize at gmail dot com

Description:

Now that Zend Optimizer Plus will make it to 5.5, I think it's time to 
resurface this discussion. PLEASE do read it before dismissing it.

Time changed. There are a lot of SuPHP (and the likes) installations out there 
that suffer from horrible performance ... and as we know, all current opcode 
cachers fail. SuPHP and the likes now account for quite a lot of php 
installations, a really non-negligible number.

All those installations would greatly benefit from a storage engine that 
survives between requests. Both users and hosting providers would be extremely 
grateful!

There are so many slow and badly written but still very popular scripts out 
there cough like WordPress cough, especially when they have all sort of other 
popular and slow plugins being executed as part of a single request. This tends 
to be the norm now with websites based on WordPress, Drupal, etc ... and a ton 
of them are hosted in SuPHP setups.

I know the cons of file-based storage but let's reconsider it for a moment.

MEMCACHED.

would be a nice solution but most probably (especially for SuPHP environments), 
hosting providers won't allow it or won't provide it at all since it would be a 
memory hog as clients fill up the server's RAM with cached php opcode.

It would still be great to have as a storage engine though.

FILE-BASED.

Everybody says cache hits would be slow. And yes, they would slower than SHM. 
However:

it would still be considerably faster than loading and executing an entire 
chain of scripts long scripts, e.g. WordPress + tons of plugins (all those php 
files have to be read anyway without an opcode cacher)

The OS would cache the opcode files transparently in its file cache -- and 
hosting providers will not disable that as they don't want their disks thrashed 
-- so this would actually be pretty much as fast as SHM-based solutions as long 
as the files are in the OS's file cache. On average, it would still be 
considerably faster than without any opcode cache at all ... probably on par 
with a Memcached-based cache which incurs network latency.

The OS would automatically take care of wiping the oldest accessed files 
from its file cache when memory fills up, so garbage collection would be pretty 
simple.

This solution would be great since the server's memory won't be hogged (as 
opposed to memcached or SHM-based solutions), and it would not require any 
dependencies for it to run (as opposed to memcached).

Both users and providers alike would enjoy a faster service + less resources 
hogged. It would be a great compromise for those numerous SuPHP-and-friends 
setups.

I know that tons of people would employ such a solution if it existed!

Hoping you'll consider this.

Cheers.

p.s. I remember when eAccelerator had file-based storage and it was making a 
great deal of difference for such big and slow scripts. Now there is no PHP 
opcode cache (that I know of) which works with SuPHP.








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

[PHP-BUG] Req #64502 [NEW]: BIG Request: files or memcached based storage (please read before dismissing)

2013-03-24 Thread normadize at gmail dot com 
From: normadize at gmail dot com
Operating system: 
PHP version:  5.5.0beta1
Package:  opcache
Bug Type: Feature/Change Request
Bug description:BIG Request: files or memcached based storage (please read 
before dismissing)

Description:

Now that Zend Optimizer Plus will make it to 5.5, I think it's time to
resurface this discussion. PLEASE do read it before dismissing it.

Time changed. There are a lot of SuPHP (and the likes) installations out
there that suffer from horrible performance ... and as we know, all current
opcode cachers fail. SuPHP and the likes now account for quite a lot of php
installations, a really non-negligible number.

All those installations would greatly benefit from a storage engine that
survives between requests. Both users and hosting providers would be
extremely grateful!

There are so many slow and badly written but still very popular scripts out
there cough like WordPress cough, especially when they have all sort of
other popular and slow plugins being executed as part of a single request.
This tends to be the norm now with websites based on WordPress, Drupal, etc
... and a ton of them are hosted in SuPHP setups.

I know the cons of file-based storage but let's reconsider it for a
moment.

MEMCACHED.

would be a nice solution but most probably (especially for SuPHP
environments), hosting providers won't allow it or won't provide it at all
since it would be a memory hog as clients fill up the server's RAM with
cached php opcode.

It would still be great to have as a storage engine though.

FILE-BASED.

Everybody says cache hits would be slow. And yes, they would slower than
SHM. However:

it would still be considerably faster than loading and executing an
entire chain of scripts long scripts, e.g. WordPress + tons of plugins (all
those php files have to be read anyway without an opcode cacher)

The OS would cache the opcode files transparently in its file cache --
and hosting providers will not disable that as they don't want their disks
thrashed -- so this would actually be pretty much as fast as SHM-based
solutions as long as the files are in the OS's file cache. On average, it
would still be considerably faster than without any opcode cache at all ...
probably on par with a Memcached-based cache which incurs network latency.

The OS would automatically take care of wiping the oldest accessed
files from its file cache when memory fills up, so garbage collection would
be pretty simple.

This solution would be great since the server's memory won't be hogged (as
opposed to memcached or SHM-based solutions), and it would not require any
dependencies for it to run (as opposed to memcached).

Both users and providers alike would enjoy a faster service + less
resources hogged. It would be a great compromise for those numerous
SuPHP-and-friends setups.

I know that tons of people would employ such a solution if it existed!

Hoping you'll consider this.

Cheers.

p.s. I remember when eAccelerator had file-based storage and it was making
a great deal of difference for such big and slow scripts. Now there is no
PHP opcode cache (that I know of) which works with SuPHP.



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

Bug #64499 [Opn->Fbk]: test on php version = 5.3.13 and 5.3.5

2013-03-24 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=64499&edit=1

 ID: 64499
 Updated by: paj...@php.net
 Reported by:dhaliwaljee at gmail dot com
 Summary:test on php version = 5.3.13 and 5.3.5
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:GD related
 Operating System:   all
 PHP Version:5.3.23
 Block user comment: N
 Private report: N

 New Comment:

Or be sure that no space or other empty characters (or non empty :) are sent 
before the image, like a new line/space before the opening http://localhost/Test/index.php"; cannot be displayed because it 
contains errors.






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

Bug #64499 [Opn]: test on php version = 5.3.13 and 5.3.5

2013-03-24 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=64499&edit=1

 ID: 64499
 Updated by: larue...@php.net
 Reported by:dhaliwaljee at gmail dot com
 Summary:test on php version = 5.3.13 and 5.3.5
 Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   all
 PHP Version:5.3.23
 Block user comment: N
 Private report: N

 New Comment:

I can not reproduce this, did you build PHP with bundled gd?


Previous Comments:

[2013-03-24 07:10:50] dhaliwaljee at gmail dot com

Description:

I have problem with imagepng;

"imagepng()" This code shows broken image on browser, but its working fine to 
save 
the image on local disk. for example: imagepng($image,"a.png"); is working but 
I 
don't want to save this file.

Test script:
---
$image = imagecreatetruecolor(200, 400) or die("a");
$bg = imagecolorallocate($image, 255, 255, 255) or die("d");

imagestring($image, 12, 10, 100, "Hello", $bg) or die("b");
header('Content-type: image/png');
imagepng($image) or die("c");


Expected result:

"Hello" Image on Browser

Actual result:
--
Broken Image on Chrome
and 
Firefox output:
The image "http://localhost/Test/index.php"; cannot be displayed because it 
contains errors.






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

[PHP-BUG] Bug #64501 [NEW]: openssl cannot work with non-default engines/algos

2013-03-24 Thread eugene at zhegan dot in 
From: eugene at zhegan dot in
Operating system: irrelevant
PHP version:  Irrelevant
Package:  OpenSSL related
Bug Type: Bug
Bug description:openssl cannot work with non-default engines/algos

Description:

openssl extension cannot work with non-default engines/algos, for example
GOST.

I have a set of openssl 1.0.1x binaries on various OSes, including Linux
Debian Wheezy, Solaris 10 x86, Solaris 11 x86, Solaris 11.1. x86. I have a
GOST-enabled configuration file, containing a set of parameters:

openssl_conf = openssl_def

[openssl_def]
oid_section = new_oids
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/local/openssl/lib/engines/libgost.so
default_algorithms = ALL

All of my openssl console utilities are able to create certificates and
private keys using GOST engine/algos and sign/verify S/MIME with it:

OPENSSL_CONF=/usr/local/openssl/ssl/openssl-gost.cnf
export OPENSSL_CONF

/usr/local/openssl/bin/openssl req -x509 -engine gost -newkey
GOST2001:gost2001.parfile -keyout key.pem -out cert.pem -nodes
(file is created)

/usr/local/openssl/bin/openssl req -x509 -engine gost -newkey
GOST2001:gost2001.parfile -keyout key.pem -out cert.pem -nodes
(certificate is created)

/usr/local/openssl/bin/openssl cms -sign -signer cert.pem -inkey key.pem
-in msg.txt -out signed.txt
(S/MIME is signed)

None of my PHP binaries, built with same openssl libraries are capable of
using such engine/algo. They all complain about non-supported algorithm.

Not only one openssl_pkcs7_sign() is affected, but the whole set of
openssl_* calls. The same thing applies to loading and testing private keys
using PHP and openssl_pkey_get_private() call and so on.

This is reproducible on various PHP versions, including 5.3.23, 5.4.11,
5.4.12 and so on.

This is related to bugs:

https://bugs.php.net/bug.php?id=63992
https://bugs.php.net/bug.php?id=60157
https://bugs.php.net/bug.php?id=54473

Further investigation using truss/strace/ktrace OS-specific utilities shows
that OPENSSL_CONF environment variable is totally ignored, at least I don't
see any open() on a file pointed with OPENSSL_CONF variable. Furthermore,
if being used inside a default configuration file, this does nothing,
because it's totally ignored by the PHP, thus only defaults are used.

Test script:
---
 "j...@example.com", // keyed syntax
  "From: HQ ", // indexed syntax
  "Subject" => "Eyes only")
)) {
} else {
echo openssl_error_string(), "\n";
}
?>

Expected result:

This code should produce a valid S/MIME file.

Actual result:
--
This code now produces a set of errors and warnings:

# php sign.php
PHP Warning:  openssl_pkcs7_sign(): error getting private key in
/home/emz/openssl/sign.php on line 8
error:0606F076:digital envelope routines:EVP_PKCS82PKEY:unsupported private
key algorithm

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

[PHP-BUG] Bug #64500 [NEW]: Impossible to disable Phar::interceptFileFuncs() behaviour

2013-03-24 Thread exbeinfo at gmail dot com 
From: exbeinfo at gmail dot com
Operating system: Windows 7
PHP version:  5.4.13
Package:  PHAR related
Bug Type: Bug
Bug description:Impossible to disable Phar::interceptFileFuncs() behaviour

Description:

Current implementation of Phar stub doesn't provide any way to disable
impact of 
Phar::interceptFileFuncs().
If you tried to run the test script for text file in the same folder
php my.phar test.txt:
 File:test.txt
 Path:C:\projects\PrimordialCode\php\glitches\open stat issue\test.txt
 is_file:
 is_readable:
 file_exists:
 file_get_contents:I'm the test text.

The same execution for test.php:
php my.phar test.php

 File:test.php
 Path:C:\projects\PrimordialCode\php\glitches\open stat issue\test.php
 is_file:1
 is_readable:1
 file_exists:1
 file_get_contents:https://github.com/php/php-src/blob/master/ext/phar/stub.h
E.g. line with Phar::interceptFileFuncs() hardcoded call:
static const char newstub1_0[] = "';\n\nif (in_array('phar', 
stream_get_wrappers()) && class_exists('Phar', 0)) 
{\nPhar::interceptFileFuncs();\n  



Test script:
---
setStub($phar->createDefaultStub("test.php"));

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

[PHP-BUG] Bug #64499 [NEW]: test on php version = 5.3.13 and 5.3.5

2013-03-24 Thread dhaliwaljee at gmail dot com 
From: dhaliwaljee at gmail dot com
Operating system: all
PHP version:  5.3.23
Package:  GD related
Bug Type: Bug
Bug description:test on php version = 5.3.13 and 5.3.5

Description:

I have problem with imagepng;

"imagepng()" This code shows broken image on browser, but its working fine
to save 
the image on local disk. for example: imagepng($image,"a.png"); is working
but I 
don't want to save this file.

Test script:
---
$image = imagecreatetruecolor(200, 400) or die("a");
$bg = imagecolorallocate($image, 255, 255, 255) or die("d");

imagestring($image, 12, 10, 100, "Hello", $bg) or die("b");
header('Content-type: image/png');
imagepng($image) or die("c");


Expected result:

"Hello" Image on Browser

Actual result:
--
Broken Image on Chrome
and 
Firefox output:
The image "http://localhost/Test/index.php"; cannot be displayed because it

contains errors.

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